Content-Transfer-Encoding on 8bit for UTF-8 emails from gerrit can cause problems with outlook

[Bailey, Darragh]

Number of developers noticed that within outlook the emails from gerrit
exhibited 2 problems.

1) Every line appeared to have double carriage return, so lots of extra
line spaces appearing.
2) Outlook wouldn't make any of the urls clickable


This appears to be connected to the use of the 8bit setting for
Content-Transfer-Encoding. It may also only appear in certain set ups,
since the 8BITMIME capability on most email MTA is supposed to be able
to handle this type on encoding, however what I've seen internally is
that it causes problems for Outlook when dealing with emails with UTF-8
encoded bodies.


I'm unable to check all the MTA's between the gerrit instance support
the 8BITMIME extension. It may also be that an antivirus or spam filter
along the way is causing the problem.


Some testing has suggested that the following solutions result in
Outlook being able to format UTF-8 emails correctly as well as convert
all urls contained to click-able links (provided it is enabled).

1) Change the encoding to 'quoted-printable' which appears to work more
consistently and is part of the basic SMTP (i.e. no extensions required)

2) Encode the message in base64 and set Content-Transfer-Encoding to
base64 also works consistently.


Would option 1 an acceptable change?

--
Regards,
Darragh Bailey

[Magnus Bäck]

On Thursday, May 17, 2012 at 13:33 EDT,

"Bailey, Darragh" <dba...@hp.com> wrote:

> Number of developers noticed that within outlook the emails from
> gerrit exhibited 2 problems.
>
> 1) Every line appeared to have double carriage return, so lots of
> extra line spaces appearing.
> 2) Outlook wouldn't make any of the urls clickable

At least reasonably new versions of Outlook (or Exchange, really)
doesn't have issues with messages produced by Gerrit, but it's possible
that you have a broken gateway inbetween (or that Gerrit's SMTP client
doesn't mark its 8-bit messages with "Content-Transfer-Encoding: 8-bit",
but that seems unlikely). A sending SMTP server should either convert an
8-bit message to use a 7-bit encoding if a receiving server doesn't
announce 8BITMIME, or bounce the message.

> This appears to be connected to the use of the 8bit setting for
> Content-Transfer-Encoding. It may also only appear in certain set ups,
> since the 8BITMIME capability on most email MTA is supposed to be able
> to handle this type on encoding, however what I've seen internally is
> that it causes problems for Outlook when dealing with emails with
> UTF-8 encoded bodies.
>
> I'm unable to check all the MTA's between the gerrit instance support
> the 8BITMIME extension. It may also be that an antivirus or spam
> filter along the way is causing the problem.

Yes, antivirus and spam gateways are generally known for their poor
implementation of SMTP standards. Last time I looked, Cisco PIX
appliances had various issues with SMTP when the SMTP fixup feature
was enabled (including disabling ESMTP alltogether). Please complain
to the vendor.

> Some testing has suggested that the following solutions result in
> Outlook being able to format UTF-8 emails correctly as well as convert
> all urls contained to click-able links (provided it is enabled).
>
> 1) Change the encoding to 'quoted-printable' which appears to work
> more consistently and is part of the basic SMTP (i.e. no extensions
> required)
>
> 2) Encode the message in base64 and set Content-Transfer-Encoding to
> base64 also works consistently.
>
> Would option 1 an acceptable change?

It's not my call, but I think it's reasonable. While I hate workarounds
for broken systems that violate established standards, interoperability
takes precedence.

--
Magnus Bäck
ba...@google.com