https://gitlab.synchro.net/main/sbbs/-/commit/7b05a61321b1d432e9503924
Modified Files:
src/smblib/smbtxt.c
Log Message:
Fix new GCC warning about return type.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/d23ad38ab8face340c90f118
Modified Files:
src/smblib/smbtxt.c
Log Message:
Fix heap corruption in smb_getattachment() for blank attachments

MSVC detected heap corruption from this function when the attachment was 0-bytes in length. Good catch.

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/3503816fa5247306ec9ef37b
Modified Files:
src/smblib/smbtxt.c
Log Message:
Replace sprintf() calls with safe_snprintf()

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/6895c8daf038e7d39a2330eb
Modified Files:
src/smblib/smbtxt.c
Log Message:
Fix heap corruption of qp_decode()

qp_decode (quoted-printable in-place decode of a string) could write 2 characters *beyond* the allocated buffer by appending "\r\n" to a string that was not quoted-printable in the first place. i.e. the contents of buf were not actually changed in the decode loop. This could result in a corrupted heap and crash of sbbs or smbutil when reading such a message.

This change may result in a lack of CRLF appended to decoded plain text output, so we'll have to keep an eye out for that and resolve it some other way. One possibility could be to only append the CRLF if the destination pointer is sufficiently behind the source pointer.

This solves the crash that Kirkman reported with a specific message in his "mail" base. The header for the message said it was quoted-printable encoded, but the body text was not actually encoded at all:
OtherHeader Content-Type: text/plain; charset="iso-8859-1"
OtherHeader MIME-Version: 1.0
OtherHeader Content-Transfer-Encoding: quoted-printable

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/1ca7f708fe87ea825cb0e5af
Modified Files:
src/smblib/smbtxt.c
Log Message:
Fix decoding of tab-indented 'charset' of multi-part MIME text parts

Apple Mail apparently uses tabs to indent the charset of nested MIME parts:

e.g.
--Apple-Mail-143B9F0C-6BB4-4C8E-869B-6DE05D6B58CE
Content-Type: text/plain;
<tab>charset=utf-8
Content-Transfer-Encoding: quoted-printable

This fixes issue #483 reported by Nelgin

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/6f3b22e63b6e18522be4585d
Modified Files:
src/smblib/smbtxt.c
Log Message:
Support non-quoted MIME Content-type boundary parameters (semicolon delimited)

This should fix issue #559, for example:
Content-Type: multipart/alternative;
boundary=mk3-ebfa33c1cd454cc2b1c618f5d74b41af; charset=UTF-8

We were assuming all boundary parameter values are quoted (apparently not
true, see https://www.rfc-editor.org/rfc/rfc2046#section-5.1.1) - so support non-quoted boundary values which also may have a semicolon delimiter.

Also, truncate any white-space from a boundary value (shouldn't be there per RFC2046).

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/685cbb887a04725dc4935e19
Modified Files:
src/smblib/smbtxt.c
Log Message:
Confirm SDT FILE* is non-null

Bug occurred where this function was called with a zeroed-out smb_t and it was not handled gracefully (got an exception in stdio functions because of the
NULL std_ftp) - so handle it as gracefully as we can here.

Most bugs have 2 causes...

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/2b8e4cf5aaecfb834c50772f
Modified Files:
src/smblib/smbtxt.c
Log Message:
smblib: decode MIME attachments in nested multipart messages

The boundary= parameter value was terminated only by ';' or a closing
quote, never by the end of the header line. That is harmless for the
top-level Content-Type, which comes from a NUL-terminated header field,
but a nested part's Content-Type is a pointer into the raw message body:
when boundary= is the last parameter on its folded line - what iOS Mail
emits - every following header and body byte was swallowed into the
boundary string, so no delimiter ever matched.

Nested parts therefore yielded no attachments at all, and
smb_getplaintext() could fail on the same messages, leaving the Terminal
Server to display the entire raw MIME body - base64 and all - instead of
the readable text.

Terminate the value at the end of the header line as well, and bound the boundary= search to the part's own (possibly folded) Content-Type field:
once CRLF terminates a value, an unbounded search would otherwise pick up
a boundary= appearing later in the message text. Reject an empty
boundary, which yields the string "--" and so matches the leading dashes
of every delimiter as well as any "--" in the body. Also skip the white
space RFC822 permits around the '=', and end an unquoted value at white
space, which an RFC2046 boundary token cannot contain.

GitLab #1205

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net

https://gitlab.synchro.net/main/sbbs/-/commit/05168cb2e65c1bf6f7617a39
Modified Files:
src/smblib/smbtxt.c
Log Message:
smblib: enumerate MIME attachments across nested containers

smb_getattachment()'s index argument stepped through the parts of a
single multipart container only: mime_getpart() kept its match counter in
a local, so every level of the recursion restarted counting at zero. Two sibling containers holding one attachment each therefore yielded only the
first - index 1 found nothing - and in a message mixing depths, every attachment following the first container was unreachable.

Share the counter across the whole recursion so that index enumerates
matching parts in document order regardless of nesting.
smb_countattachments(), which walks index until it comes up empty, now
reports the true total rather than stopping at the first gap.

This was unreachable until the preceding commit, which is what made
nested containers get descended into at all.

GitLab #1205

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---
■ Synchronet ■ Vertrauen ■ Home of Synchronet ■ [vert/cvs/bbs].synchro.net