CRLF in attachments being replaced by LF

[Seb James]

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.

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