Re: multipart message with pdf file gets truncated
On Fri, 08 Apr 2011 09:27:29 -0400, Joseph Brennan wrote: > Julien Vehent 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. > > Alright, thanks for the analysis. I will try to gather more data on the server, and if possible dump the connection before it's handled by postfix. Since the client is sending the same email to another mailbox, and it works fine, I would like to make sure my setup works fine before blaming anybody else... Thanks, Julien Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: multipart message with pdf file gets truncated
Julien Vehent 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 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/
Re: multipart message with pdf file gets truncated
On Thu, 7 Apr 2011 15:53:12 -0500, Mike Eggleston wrote: > On Thu, 07 Apr 2011, Julien Vehent might have said: > >> Hi list, > > Afternoon. > > My setup is: > > cloud mail -> DMZ sendmail <- internal sendmail -> cyrus > > Mail comes from the outside to the DMZ sendmail for spam and virus > checking. The mail is held until the internal sendmail server pulls > the mail (a script I wrote), then the internal hands the email to the > internal cyrus for delivery. > > 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). > > I needed to look for a dot (.) in column one and adjust the message > before reinjection. > That's an interesting scenario. I will run a tcpdump and see what happens. However, in my case, wouldn't gmail's server behave the same way and trunk the message at the dot ? Julien Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
Re: multipart message with pdf file gets truncated
On Thu, 07 Apr 2011, Julien Vehent might have said: > Hi list, Afternoon. My setup is: cloud mail -> DMZ sendmail <- internal sendmail -> cyrus Mail comes from the outside to the DMZ sendmail for spam and virus checking. The mail is held until the internal sendmail server pulls the mail (a script I wrote), then the internal hands the email to the internal cyrus for delivery. 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). I needed to look for a dot (.) in column one and adjust the message before reinjection. HTH Mike Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
multipart message with pdf file gets truncated
Hi list, I'm trying to diagnose a problem with a user receiving PDF files that get truncated somehow. One of my user received a PDF file in his inbox today, and second part of the page of the attached PDF is blank. He asked the sender to resend the same email to an external mailbox on gmail, and the pdf was displaying fine (ruling out a possible problem on the sender's side). I went to the cyrus partition and copied the raw email in a local text file that I opened with thunderbird. The PDF is also truncated. (so it's not a MUA problem). I am trying to diagnose this, but I'm not sure where to start. The software stack is as follow: -Debian Squeeze-- -> [openldap] smtp->+--+/ | postfix | -> postgrey | | -> dspam +--+ \ `->[cyrus-imap-2.2.13-19] - Sample of the email below: == [] Message-ID: <004e01cbf535$97ac62c0$c7052840$@fr> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_NextPart_000_004F_01CBF546.5B3532C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acv1NZdYOJh+BtBQRUSMKv2Kl/KRlA== Content-Language: fr [] This is a multi-part message in MIME format. --=_NextPart_000_004F_01CBF546.5B3532C0 Content-Type: multipart/alternative; boundary="=_NextPart_001_0050_01CBF546.5B3532C0" --=_NextPart_001_0050_01CBF546.5B3532C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Salut [] --=_NextPart_001_0050_01CBF546.5B3532C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable --=_NextPart_001_0050_01CBF546.5B3532C0-- --=_NextPart_000_004F_01CBF546.5B3532C0 Content-Type: application/pdf; name="FC 2361.pdf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="FC 2361.pdf" %PDF-1.3 %=FF=FF=FF=FF 1 0 obj=0A= <<=0A= /Filter /Standard=0A= /U <1ADBE3C9C640824CF6754B336A1088DEC6510A59D6C4818C90072BDCAA5E3190>=0A= /O <20DF7A5FA972C424A023D59CC861F679B476BF87250F63CEAA69C43AB43F9F41>=0A= /P -3852=0A= /V 1=0A= [] %%EOF=0A= --=_NextPart_000_004F_01CBF546.5B3532C0-- ==END Now, without being a MIME expert, I assume that the last "NextPart" line not being followed by anything is not a good thing. Any hing on where I should look to diagnose this ? Thanks a lot, Julien Vehent Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/
