Problems with quoted-printable attachment

[Aaron Fransen-2]

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.

Even looking at the two files side-by-side (using Crimson Editor, probably not ideal for binary files) I can't see any differences.

Any thoughts folks?

Aaron

_______________________________________________
Email-SIG mailing list
Email-SIG@...
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com

[Mark Sapiro-3]

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 <mark@...>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

_______________________________________________
Email-SIG mailing list
Email-SIG@...
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com

[Aaron Fransen-2]

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 <mark@...> 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 <mark@...>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

_______________________________________________
Email-SIG mailing list
Email-SIG@...
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com

[Mark Sapiro-3]

Aaron Fransen wrote:

>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...

In my more cynical moments, I think that Microsoft's goal is to have
all Microsoft products interoperate with each other and with nothing
else.

--
Mark Sapiro <mark@...>        The highway is for gamblers,
San Francisco Bay Area, California    better use your sense - B. Dylan

_______________________________________________
Email-SIG mailing list
Email-SIG@...
Your options: http://mail.python.org/mailman/options/email-sig/lists%40nabble.com