Does/can postfix alter carriage-return/newlines into newlines?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Does/can postfix alter carriage-return/newlines into newlines?

Seb James
Hi list,

I've been using postfix for a while, and find it excellent. However, it
has come to light that some of the attachments that poeple send to me
are being altered. Specifically; carraige-return-newlines are being
replaced with newlines in certain attachments. This is very undesireable
for me, because these attachments are typically print data for which
such a modification alters the print output for the data (it's generally
test data from my customers and if it gets mangled in transit, I can't
help them).

My question is: Is this likely to be postfix's doing, or is it possible
that MailScanner is the culprit?

I couldn't find anything obvious in the config for either such as a
setting called "replace all line endings with newlines". I have
certainly configured MailScanner to allow these attachments through.
It's just they're getting modified either by postfix or MailScanner.

Many thanks,

Seb



Reply | Threaded
Open this post in threaded view
|

Re: Does/can postfix alter carriage-return/newlines into newlines?

Wietse Venema
Seb James:

> Hi list,
>
> I've been using postfix for a while, and find it excellent. However, it
> has come to light that some of the attachments that poeple send to me
> are being altered. Specifically; carraige-return-newlines are being
> replaced with newlines in certain attachments. This is very undesireable
> for me, because these attachments are typically print data for which
> such a modification alters the print output for the data (it's generally
> test data from my customers and if it gets mangled in transit, I can't
> help them).
>
> My question is: Is this likely to be postfix's doing, or is it possible
> that MailScanner is the culprit?
>
> I couldn't find anything obvious in the config for either such as a
> setting called "replace all line endings with newlines". I have
> certainly configured MailScanner to allow these attachments through.
> It's just they're getting modified either by postfix or MailScanner.

The SMTP record delimiter is CRLF. Postfix removes it (as well as
invalid CR characters at the end of a record) while receiving mail
via SMTP, and adds it when sending mail via SMTP.

The UNIX text record delimiter is LF. Postfix removes it (as well
as invalid CR characters at the end of a record) while receiving
mail via the Postfix sendmail command, and adds it when delivering
mail to local mailbox, maildir, or command.

The DOS/WINDOWS text record delimiter is CRLF. When someone sends
mail as text/plain or text/quoted-printable from DOS/WINDOWS to
UNIX, those CRLF will become LF. Just like UNIX LF will become CRLF
when sending text/plain or text/quoted-printable from UNIX to
DOS/WINDOWS.

If you must preserve CRLF, use base64 encoding.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Does/can postfix alter carriage-return/newlines into newlines?

Seb James
On Thu, 2008-07-10 at 07:13 -0400, Wietse Venema wrote:
> Seb James:
> > Hi list,
[snip]
> > Specifically; carraige-return-newlines are being
> > replaced with newlines in certain attachments.
[snip]
> > My question is: Is this likely to be postfix's doing, or is it possible
> > that MailScanner is the culprit?
[snip]

> The SMTP record delimiter is CRLF. Postfix removes it (as well as
> invalid CR characters at the end of a record) while receiving mail
> via SMTP, and adds it when sending mail via SMTP.
>
> The UNIX text record delimiter is LF. Postfix removes it (as well
> as invalid CR characters at the end of a record) while receiving
> mail via the Postfix sendmail command, and adds it when delivering
> mail to local mailbox, maildir, or command.
>
> The DOS/WINDOWS text record delimiter is CRLF. When someone sends
> mail as text/plain or text/quoted-printable from DOS/WINDOWS to
> UNIX, those CRLF will become LF. Just like UNIX LF will become CRLF
> when sending text/plain or text/quoted-printable from UNIX to
> DOS/WINDOWS.
>
> If you must preserve CRLF, use base64 encoding.

Wietse,

Many thanks for your reply.

I went back and looked at one of the messages and (to my surprise) it
was quoted-printable transfer encoding:

Content-Transfer-Encoding: quoted-printable

This clarifies the situation for me; I can now check if an attachment
has come in _without_ base64 encoding and ask the sender to re-send.

In fact, I'd quite like to reject quoted-printable attachments...

&$*"%&* Outlook (the sending MUA in this case); why does it allow the
user to send an attachment without base64??

thanks,

Seb James




Reply | Threaded
Open this post in threaded view
|

Re: Does/can postfix alter carriage-return/newlines into newlines?

Magnus Bäck
On Thursday, July 10, 2008 at 14:13 CEST,
     Seb James <[hidden email]> wrote:

> I went back and looked at one of the messages and (to my surprise) it
> was quoted-printable transfer encoding:
>
> Content-Transfer-Encoding: quoted-printable
>
> This clarifies the situation for me; I can now check if an attachment
> has come in _without_ base64 encoding and ask the sender to re-send.
>
> In fact, I'd quite like to reject quoted-printable attachments...
>
> &$*"%&* Outlook (the sending MUA in this case); why does it allow the
> user to send an attachment without base64??

I think the question you should ask is: Why doesn't the MUA used to save
the attachment convert the line breaks into the line breaks used by the
target system? A Windows MUA should save text/plain attachments with
CR/LF linebreaks and a Unix MUA should save it with LF linebreaks.

The text/plain type allows better interoperability between different
systems. It is however not a MIME type that should be used when binary
equality is necessary.

--
Magnus Bäck
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Does/can postfix alter carriage-return/newlines into newlines?

Seb James
On Thu, 2008-07-10 at 14:26 +0200, Magnus Bäck wrote:

> On Thursday, July 10, 2008 at 14:13 CEST,
>      Seb James <[hidden email]> wrote:
>
> > I went back and looked at one of the messages and (to my surprise) it
> > was quoted-printable transfer encoding:
> >
> > Content-Transfer-Encoding: quoted-printable
> >
> > This clarifies the situation for me; I can now check if an attachment
> > has come in _without_ base64 encoding and ask the sender to re-send.
> >
> > In fact, I'd quite like to reject quoted-printable attachments...
> >
> > &$*"%&* Outlook (the sending MUA in this case); why does it allow the
> > user to send an attachment without base64??
>
> I think the question you should ask is: Why doesn't the MUA used to save
> the attachment convert the line breaks into the line breaks used by the
> target system? A Windows MUA should save text/plain attachments with
> CR/LF linebreaks and a Unix MUA should save it with LF linebreaks.
>
> The text/plain type allows better interoperability between different
> systems. It is however not a MIME type that should be used when binary
> equality is necessary.

I went off and found a computer with MS Outlook on it. It automatically
makes a decision about what kind of encoding to use when attaching a
file. So, a PDF file was attached with base64 encoding, but the print
data file that my customer tried to send me was automatically typed as
"plain text" and sent as such.

I would personally prefer the default behaviour of MUAs to base64 encode
every file, because the auto-typing of files is fallible - Outlook
couldn't work out that the file was not exactly plain text in this
particular case.

I do notice that this auto-typing seems to be the norm; the Evolution
MUA, for example sends an ascii text attachment (with unix LFs) as
text/plain rather than base64 encoding it, so it follows the behaviour
of Outlook, to text/plain encode text files which appear to be "native".

Anyway - I've learned that I have to check on the encoding of print data
attachments which are sent to me.

Thanks for the replies!

very best regards,

Seb James



Reply | Threaded
Open this post in threaded view
|

RE: Does/can postfix alter carriage-return/newlines into newlines?

Banyan He-2
Hi there,

I suppose you are using ironport appliance. It can be used for implementing
this feature.

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Seb James
Sent: Thursday, July 10, 2008 10:48 PM
To: [hidden email]
Subject: Re: Does/can postfix alter carriage-return/newlines into newlines?

On Thu, 2008-07-10 at 14:26 +0200, Magnus Bäck wrote:

> On Thursday, July 10, 2008 at 14:13 CEST,
>      Seb James <[hidden email]> wrote:
>
> > I went back and looked at one of the messages and (to my surprise) it
> > was quoted-printable transfer encoding:
> >
> > Content-Transfer-Encoding: quoted-printable
> >
> > This clarifies the situation for me; I can now check if an attachment
> > has come in _without_ base64 encoding and ask the sender to re-send.
> >
> > In fact, I'd quite like to reject quoted-printable attachments...
> >
> > &$*"%&* Outlook (the sending MUA in this case); why does it allow the
> > user to send an attachment without base64??
>
> I think the question you should ask is: Why doesn't the MUA used to save
> the attachment convert the line breaks into the line breaks used by the
> target system? A Windows MUA should save text/plain attachments with
> CR/LF linebreaks and a Unix MUA should save it with LF linebreaks.
>
> The text/plain type allows better interoperability between different
> systems. It is however not a MIME type that should be used when binary
> equality is necessary.

I went off and found a computer with MS Outlook on it. It automatically
makes a decision about what kind of encoding to use when attaching a
file. So, a PDF file was attached with base64 encoding, but the print
data file that my customer tried to send me was automatically typed as
"plain text" and sent as such.

I would personally prefer the default behaviour of MUAs to base64 encode
every file, because the auto-typing of files is fallible - Outlook
couldn't work out that the file was not exactly plain text in this
particular case.

I do notice that this auto-typing seems to be the norm; the Evolution
MUA, for example sends an ascii text attachment (with unix LFs) as
text/plain rather than base64 encoding it, so it follows the behaviour
of Outlook, to text/plain encode text files which appear to be "native".

Anyway - I've learned that I have to check on the encoding of print data
attachments which are sent to me.

Thanks for the replies!

very best regards,

Seb James





Reply | Threaded
Open this post in threaded view
|

RE: Does/can postfix alter carriage-return/newlines into newlines?

Seb James
On Thu, 2008-07-10 at 23:27 +0800, Banyan He wrote:
> Hi there,
>
> I suppose you are using ironport appliance. It can be used for implementing
> this feature.

I'm not using an ironport appliance; just
postfix/MailScanner/spamassassin on a Debian Etch system running on a
little Geode LX800 processor (it only has to deal with a few mailboxes).

Seb

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of Seb James
> Sent: Thursday, July 10, 2008 10:48 PM
> To: [hidden email]
> Subject: Re: Does/can postfix alter carriage-return/newlines into newlines?
>
> On Thu, 2008-07-10 at 14:26 +0200, Magnus Bäck wrote:
> > On Thursday, July 10, 2008 at 14:13 CEST,
> >      Seb James <[hidden email]> wrote:
> >
> > > I went back and looked at one of the messages and (to my surprise) it
> > > was quoted-printable transfer encoding:
> > >
> > > Content-Transfer-Encoding: quoted-printable
> > >
> > > This clarifies the situation for me; I can now check if an attachment
> > > has come in _without_ base64 encoding and ask the sender to re-send.
> > >
> > > In fact, I'd quite like to reject quoted-printable attachments...
> > >
> > > &$*"%&* Outlook (the sending MUA in this case); why does it allow the
> > > user to send an attachment without base64??
> >
> > I think the question you should ask is: Why doesn't the MUA used to save
> > the attachment convert the line breaks into the line breaks used by the
> > target system? A Windows MUA should save text/plain attachments with
> > CR/LF linebreaks and a Unix MUA should save it with LF linebreaks.
> >
> > The text/plain type allows better interoperability between different
> > systems. It is however not a MIME type that should be used when binary
> > equality is necessary.
>
> I went off and found a computer with MS Outlook on it. It automatically
> makes a decision about what kind of encoding to use when attaching a
> file. So, a PDF file was attached with base64 encoding, but the print
> data file that my customer tried to send me was automatically typed as
> "plain text" and sent as such.
>
> I would personally prefer the default behaviour of MUAs to base64 encode
> every file, because the auto-typing of files is fallible - Outlook
> couldn't work out that the file was not exactly plain text in this
> particular case.
>
> I do notice that this auto-typing seems to be the norm; the Evolution
> MUA, for example sends an ascii text attachment (with unix LFs) as
> text/plain rather than base64 encoding it, so it follows the behaviour
> of Outlook, to text/plain encode text files which appear to be "native".
>
> Anyway - I've learned that I have to check on the encoding of print data
> attachments which are sent to me.
>
> Thanks for the replies!
>
> very best regards,
>
> Seb James
>
>
>
>
>
>
>