multipart message with pdf file gets truncated

[Joseph Brennan]

Julien Vehent <julien at 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 <mikeegg1 at 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