CRLF in attachments being replaced by LF

[Seb James]

On Thu, 2008-07-10 at 13:15 +0100, Seb James wrote:
> On Thu, 2008-07-10 at 10:48 +0100, Seb James wrote:
> > On Thu, 2008-07-10 at 02:34 -0700, Neal Morgan wrote:
> > > Seb James wrote:
> > > > Hi list,
> > > >
> > > > I have a problem with some attachments being sent to me.
> > > >
> > > > I am using postfix and MailScanner and SpamAssassin to process
> > > incoming
> > > > mail.
> > > >
> > > > The attachments are raw print data, containing escape characters of
> > > > various types and also CRLF pairs, as well as formfeeds, and lonely LF
> > > > characters.
> > > >
> > > > Somewhere, the CRLF are being converted to LF, which messes up the
> > > print
> > > > data (test docs sent to me by customers for testing and problem
> > > > resolution).
> > > >
> > > > I suspect spamassassin, am I right?
> > > >
> > > > Any way to turn spamassassin off for certain attachment file types,
> > > such
> > > > as any files ending in .prn and .dat? I know I can deny or allow files
> > > > based on file types, but what about spamassassin scanning depending on
> > > > file type?
> > > >
> > > > Thanks in advance for any help,
> > > >
> > > > Seb James
> > > 
> > > Just a wild guess - but since SMTP expects <CRLF>.<CRLF> to end the data
> > > phase, is it possible that MUA (sending side) is performing this
> > > replacement to prevent message truncation during delivery?
> > > 
> > > Try having the sender zip the file or rename to a type that Windows
> > > doesn't consider text...
> > 
> > Thanks for the reply Neil,
> > 
> > I think the attachment would be base64 encoded, meaning that the sending
> > side wouldn't see any CRLF to strip out.
> 
> In fact, now I look back at the messsage source, the attachment transfer
> encoding was quoted-printable, rather than base64, so the problems with
> CRLF being modified into LF are quite understandable.
> 
> &*$&%£ MS Outlook (the MUA here) for allowing users to send attachments
> quoted-printable!

I find that other mail user agents will select quoted-printable if they
think that an attachment is "native" clear text. Evolution certainly
does. So I just have to check the encoding of important print data
attachments to make sure it is base64 and if not, ask the customer to
re-send a zip file which will protect the data.

> > I'm sure this is happening in my MTA, because the same message sent to
> > multiple recipients including me and someone receiving their email via a
> > different chain (including some Linux based MTA for their domain then a
> > Windows mail client) arrived with the attachment different in each case.
> > 
> > I really want to avoid asking the sender to do anything if I can
> > possibly get these mails to arrive intact!
> > 
> > best,
> > 
> > Seb
> > 
> > 
> > 
> 
> 
>