Julien Vehent <jul...@linuxwall.info> wrote-- > Now, without being a MIME expert, I assume that the last "NextPart" > line not being followed by anything is not a good thing.
No, that last boundary marks the end of the mime part, signfifed by the two hyphens at the end. In this case it's the end of the whole message. That happens to prove that the message is not truncated. Only the software that created the message would have written that end boundary. My conclusion is that the message arrived as is. Either the original PDF was damaged, or the message was created with damage. Mike Eggleston <mikee...@mac.com> wrote-- > My truncation problem was happening when the internal server pulled > the mail, then injected the mail into the internal sendmail. At the > reinjection time there were a few messages that had a dot (.) in column > one. Per the RFC a dot (.) in column one is the signal to end the SMTP > input session (the data command). No, the end of DATA is signalled by the five-character sequence CR LF dot CR LF, that is, a dot on a line by itself. So your software is buggy if it stops at CR LF dot without examining what follows dot. Joseph Brennan Lead Email Systems Engineer Columbia University Information Technology ---- Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
