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)