You are correct. I figured it out about 10 minutes after I sent my email. Microsoft is sending LF instead of CR/LF. A simple string-replace fixed the problem.
Found it on some page talking about how Microsoft likes to break the standards... Thanks Mark! On Wed, Mar 4, 2009 at 4:00 PM, Mark Sapiro <m...@msapiro.net> wrote: > Aaron Fransen wrote: > > > >I have a MIME email I've received generated by Microsoft Windows Mail > >6.0.6001.18000. > > > >In it are two PDF documents encoded using quoted-printable. > > > >No matter what I do, or what method I try, I can't seem to decode the > darned > >attachments properly! Yet Outlook has no issues decoding. I've tried > quopri, > >email, even wrote my own decoder to see what I could figure out. All of > them > >generate a file exactly 150 bytes shorter than the version Outlook > >generated. > > > Are they missing a \r at the end of each of 150 lines? > > If that's the difference, I'm not sure that there's anything you can do > about it as the sending MUA is not properly encoding the data. I.e. if > a <CRLF> vs a <LF> line terminator is significant, I think the data > should be base64 encoded. I know Outlook and maybe other Microsoft > MUAs do encode some PDFs as quoted-printable, but I suspect this is > wrong. > > OTOH, if some data are quoted-printable encoded as > > something=0D=0A= > or other > > or equivalent, that should decode as > > something\r\nor other > > and if it is decoded as > > something\nor other > > then the decoding is wrong > > -- > Mark Sapiro <m...@msapiro.net> The highway is for gamblers, > San Francisco Bay Area, California better use your sense - B. Dylan > >
_______________________________________________ Email-SIG mailing list Email-SIG@python.org Your options: http://mail.python.org/mailman/options/email-sig/archive%40mail-archive.com
