From: Bill Cole (postfixlists-070913billmail.scconsult.com)
Date: Wed Sep 19 2007 - 08:11:23 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

At 8:38 PM -0700 9/18/07, Bill Landry wrote:
>I've been struggling with my relay provider trying to convince them to
>advertise 8bitmime in their ehlo exchange, however they are opposed to
>doing this. They say:
>============
>"As for advertising 8bit MIME with the accept_8bitmime option in Exim,
>that's not something we are going to change:
>
>http://www.exim.org/exim-html-current/doc/html/spec_html/ch14.html#SECTalomo
>
> This option causes Exim to send 8BITMIME in its response
>to an SMTP EHLO
> command, and to accept the BODY= parameter on MAIL
>commands. However,
> though Exim is 8-bit clean, it is not a protocol
>converter, and it takes no
> steps to do anything special with messages received by this route.
> Consequently, this option is turned off by default.
>
>We are not going to make that sort of change the behavior of our
>service since many other
>users who are relying on our current behavior would have the
>opposite problem :)"
>============
>
>It seems to me that it is pretty standard for MTAs to announce
>"250-8BITMIME", so what would the "opposite problem" be that they
>are referring to above? What could break if they started announcing
>"250-8BITMIME" with their ehlo reply?

Then they would need to take responsibility for doing encoding
conversion when handing the mail to other MTA's that do not support
8BITMIME. I don't have any direct experience using Exim, but the bit
you quote from the docs seems to be saying that Exim does not do such
conversion. That's a very strong argument to NOT announce the feature.

>The problem I am experiencing with this is that when mail is sent
>via SquirrelMail, it is sent as "Content-Transfer-Encoding: 8bit",
>however, it appears that since the relay service is not announcing
>8BITMIME, Postfix is sending the message with
>"Content-Transfer-Encoding: quoted-printable". And since the
>message has already been signed with both DK and DKIM, and the
>"Content-Transfer-Encoding" is included in the signing as 8bit, the
>signatures fail verification on the receiving end.
>
>I know I can tell the milters to ignore the
>"Content-Transfer-Encoding" header in the signing,

That would seem to be one correct solution. Another would be to do
the conversion ahead of the signing so that you sign a header that
won't need changing.

You cannot be sure that all transport paths will be able to handle
8-bit encoding and the correct ways for an MTA to deal with that are
to either fail the message and send a bounce that most users are
unlikely to understand OR to convert the message to a 7-bit encoding.
Conversion is the more common and useful approach, and you should
expect it to happen to your mail frequently. If you sign your mail in
a way that demands an 8-bit transport, you will get breakage.

>however, I'm
>wondering if there is a way to force "Content-Transfer-Encoding:
>8bit" to this relay provider, as it appears they will accept 8bit,
>even though they don't announce it. This was confirmed using swaks
>and hard setting Content-Transfer-Encoding to 8bit:
>
> swaks -s xxx.xxx.xxx.xxx -f testexample.com \
> -t testexample.net --header="Content-Transfer-Encoding: 8bit"
>
>Thoughts? Thanks for any feedback...!

Setting the header is not magic. Postfix is behaving correctly by
doing the encoding conversion when it hands mail to a receiver that
does not advertise its ability to handle 8-bit MIME, and it seems
that Exim is correct in not advertising such an ability. All you
could do by forcibly setting the header would be to make the message
break randomly downstream wherever it is passed blindly by Exim.
--
Bill Cole
billscconsult.com

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]