• src/sbbs3/mailsrvr.cpp

    From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Fri Aug 7 15:55:33 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/7df7ab3a7d825846e02790fc
    Modified Files:
    src/sbbs3/mailsrvr.cpp
    Log Message:
    Don't tag an authenticated user's local mail as netmail (issue #1215)

    An SMTP-authenticated user's message to a local recipient was stored with SENDER_NETTYPE of NET_INTERNET and a SENDERNETADDR of the sender's own
    address on one of this system's own domains, even though both parties are
    local users. Mail readers key off the sender net type to decide between a netmail reply and a regular e-mail reply, so replying to such a message
    tried, and failed, to send netmail to an address this system won't route.

    The NET_NONE branch dates from d21065229b (knee-4-prepare, 2009-11-12),
    which qualified it with "subnum != INVALID_SUB" because it was added for messages posted to a sub-board via authenticated SMTP. E-mail was never covered.

    The sender header fields are written once, before the per-recipient loop,
    and a single submission can name both local and remote recipients, so the
    net address can't simply be dropped: for a recipient on another system it
    is what selects the reverse-path as the envelope sender, and what routes a delivery-failure notice back. Set the sender to the authenticated user's
    alias up front, and add the sender net type and address per recipient
    copy, only for the copies whose recipient is not local.

    Mail leaving the system is unchanged. A local recipient's copy now looks
    like any other local e-mail: sender alias plus SENDEREXT, no net address.
    The From header presented over POP3 and IMAP is unaffected, as it is
    rendered from the preserved RFC822FROM field.

    Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Sun Aug 9 07:19:11 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/6bd3794453efbefffbb6ebd7
    Modified Files:
    src/sbbs3/mailsrvr.cpp
    Log Message:
    mailsrvr: don't pass an uninitialized buffer to filterFile::listed()

    email_addr_is_exempt() declared a local 'fname' buffer and handed it to listed() as the optional second search string without ever initializing
    it. That argument is a second candidate matched against the same list,
    so trash_in_list() ran parse_ip() and findstr_compare() over
    uninitialized stack memory: a sender could be spuriously exempted from
    DNSBL checking by whatever the stack happened to hold, and the compare
    walks past the buffer when that junk contains no terminator.

    The buffer is a leftover from the pre-cache API, where it held the dnsbl_exempt.cfg path for findstr(netmail, fname). 8409089bbc (pulse-4-memories, 2026-02-12) replaced that call with a cached
    filterFile lookup and dropped the SAFEPRINTF that filled the buffer,
    but kept passing it.

    Only one address is looked up here, so drop the argument (it defaults
    to nullptr) along with the buffer.
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Tue Aug 11 21:39:59 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/2f379c7389b043fc4da124a6
    Modified Files:
    src/sbbs3/mailsrvr.cpp
    Log Message:
    mailsrvr: don't send or kill attachments during a POP3 TOP (issue #1226)

    TOP and RETR share sockmsgtxt(), where maxlines bounds only the body-text
    loop: the attachment loop that follows it ran unconditionally. A
    headers-only "TOP n 0" therefore MIME-encoded and transmitted the entire attachment, then removed the file when MSG_KILLFILE was set, destroying
    it during what the client had asked for as a preview. A client that
    sweeps a mailbox with TOP before choosing what to RETR consumed every
    kill-file attachment in the preview pass and received an empty MIME part
    on the retrieval that followed.

    Skip the attachment loop for a partial fetch, closing the multipart after
    the truncated text part so that TOP and RETR still describe the same
    message structure.

    Separately, a successful RETR removed the attachment file but left MSG_FILEATTACH set on a message that remains in the mailbox, so every
    later fetch re-attempted an attachment whose file the earlier fetch had deleted:

    !ERROR opening/encoding/sending data/file/NNNN.in/attachment.png

    Any client configured to leave mail on the server hits that on its next
    poll, and with two clients polling one mailbox the second never receives
    the attachment at all. Report the kill back to the POP3 thread and clear MSG_FILEATTACH/MSG_KILLFILE where the header is already being rewritten.
    That update no longer depends on MAIL_OPT_NO_READ_POP3, which is
    precisely the setting a leave-mail-on-server client runs under.
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Rob Swindell (on Debian Linux)@1:103/705 to Git commit to main/sbbs/master on Tue Aug 18 22:04:59 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/126ed841933b774477b5c1b1
    Modified Files:
    src/sbbs3/mailsrvr.cpp
    Log Message:
    mailsrvr: name the rejected address in the sender-auth 550 replies

    The 550 reply for an unauthorized MAIL FROM or From: address named only the address to use instead, never the address that was rejected. The submitter
    is left to guess which of the settings in their mail client the server is objecting to, and only the server log records it -- which the submitter
    cannot read.

    Seen on Vertrauen: "550 Sender address not authorized for this account, try <[email protected]>" was read as a statement about the server
    hostname the client had connected to, and answered with a question about
    which hostname to use, when the setting at fault was the sender address.

    Grow from_errmsg to 512 bytes: the header 'FROM' message now formats two addresses of up to 127 characters each, which 256 bytes could truncate.

    Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
    --- SBBSecho 3.37-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)