1. Forum
  2. DOVE-Net
  3. Synchronet Programming

  • src/sbbs3/mailsrvr.cpp

    From Rob Swindell (on Windows@VERT to Git commit to main/sbbs/m on Tuesday, December 30, 2025 22:20:00
    https://gitlab.synchro.net/main/sbbs/-/commit/74c037b2205ba9070e55ddc1
    Modified Files:
    src/sbbs3/mailsrvr.cpp
    Log Message:
    Fix mail archive feature

    Broken in commit f820805f0 (fixing Coverity issue, sigh)

    Once the mail archive directory existed (once successfully created), the function would just fail.
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows@VERT to Git commit to main/sbbs/m on Saturday, January 17, 2026 04:11:00
    https://gitlab.synchro.net/main/sbbs/-/commit/c5daf067bae2f7666c4ccfc2
    Modified Files:
    src/sbbs3/mailsrvr.cpp
    Log Message:
    Strip ctrl chars "B" mime-encoded words in incoming message header fields

    Per RFC2047: "Only printable and white space character data should be encoded using this scheme."

    Apparently TikTok doesn't follow that advice. Here's one example:

    68% #614159 (1741720) TikTok Header field contains control characters
    ...
    Subject 6C 69 76 6B 61 70 73 7A 6F 6F 20 70 6F 73 74 65 64 3A 20 4D 75 66 66 69 6E 20 73 61 69 64 20 0A 4E 6F 20 74 68 61 6E 6B 73 F0 9F AB A0

    Which expands to:

    "livkapszoo posted: Muffin said
    No thanks¨"

    This could do weird things when the message is viewed (depending on the viewer) and triggers the chksmb error: Control Characters in Header Fields (!): 1
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Wednesday, February 11, 2026 17:27:28
    https://gitlab.synchro.net/main/sbbs/-/commit/47560c50d5d83383947c349a
    Modified Files:
    src/sbbs3/mailsrvr.cpp
    Log Message:
    Remove quotes from RCPT TO: <forward-path> before comparing to local names

    This resolve an issue observed with Thunderbird sending to local:<name>@bbs: Unknown User: <"local:name"@vert.synchro.net>.

    Presumably, Thunderbird is adding the quotes because of the colon. I've not seen this issue before, so perhaps this is new behavior of Thunderbird. In any case, RFC[2]821 specifies that the RCPT TO argument is a Mailbox and that the local-part of a Mailbox may be a quoted-string (instead of a dot-string). So, Synchronet hasn't been compliant in this regard all these years.

    No special parsing of \" is implemented since we don't support quotes in names anyway. RFC 821 says the character following a backslash (<x>) may be
    "any one of the 128 ASCII characters (no exceptions)" - that implies all control characters too, which sounds really dangerous. That language seems fixed in RFC 2821, but I'm not trying to solve all the crazy escaping possibilities in this simple commit.

    The original RCPT TO argument (with quotes, if present) is still stored for subsequent forwarding or whatever.
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Thursday, February 12, 2026 03:12:06
    https://gitlab.synchro.net/main/sbbs/-/commit/8409089bbc3b1e11c0d140f3
    Modified Files:
    src/sbbs3/mailsrvr.cpp
    Log Message:
    Cache the dnsbl_exempt.cfg file (mine is 2MB)

    ... this file was being read multiple times for every incoming SMTP message
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Thursday, February 12, 2026 16:38:59
    https://gitlab.synchro.net/main/sbbs/-/commit/63ee13b03befd229da39f7d1
    Modified Files:
    src/sbbs3/mailsrvr.cpp
    Log Message:
    Insure dnsbl_result is always zero-initialized

    Fix recently-introduced bug
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Friday, February 13, 2026 00:34:20
    https://gitlab.synchro.net/main/sbbs/-/commit/3b05d005e25a668fdd78aa20
    Modified Files:
    src/sbbs3/mailsrvr.cpp
    Log Message:
    Always clear the "from extension" for newly created bounce messages

    This bug caused chksmb reported errors in bounced messages (e.g. from listserver):

    97% #635909 (30AEF20) Mail Delivery Subsystem From extension mismatch MSGERR: From extension ((null)) does not match index (1)

    packing or running fixsmb on the mail base would correct the index, but this
    is the real fix.
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Tuesday, October 13, 2026 23:29:30
    https://gitlab.synchro.net/main/sbbs/-/commit/d4f33e47976414b619032701
    Modified Files:
    src/sbbs3/mailsrvr.cpp
    Log Message:
    mailsrvr: stop sending the message after a body line fails to send

    When a send failed partway through the message body, sockmimetext()
    broke out of the body loop but still went on to MIME-encode any
    attachments and send the "." end-of-data terminator over the dead
    connection. With DKIM signing enabled, that terminator finalized the
    verify pass's body hash over the truncated body, so every dropped
    connection mid-DATA was also logged as the error "DKIM body hash changed between sign and send - message delivery aborted", though nothing had
    changed and the delivery had already failed.

    Return as soon as a body line fails to send, as is already done when the
    header terminator fails.

    Fixes #1279

    Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Debian Linux)@VERT to Git commit to main/sbbs/master on Tuesday, October 13, 2026 23:29:30
    https://gitlab.synchro.net/main/sbbs/-/commit/1728d248fb27d5d1cf0737e9
    Modified Files:
    src/sbbs3/mailsrvr.cpp
    Log Message:
    mailsrvr: POP3 LIST/UIDL skips unreadable messages instead of stopping

    In the POP3 LIST and UIDL (all messages) loop, a failure to read a
    message's index entry, lock its header, or read its header ended the
    listing early. Every message after the bad one was then missing from
    the client's view of the mailbox. Skip just the bad message instead:
    the error is still logged, and the other messages keep their POP3
    numbers, so RETR and DELE still work on them. A failed socket write
    still ends the loop.

    Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net