[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postfix-users
Subject:    Re: base64 encoded emails
From:       Richard Damon <Richard () Damon-Family ! org>
Date:       2019-10-17 12:07:22
Message-ID: a1be39ea-9d06-1cea-4090-73814ccb6ec9 () Damon-Family ! org
[Download RAW message or body]

On 10/17/19 4:48 AM, Fourhundred Thecat wrote:
> Hello,
>
> I would like to ask what the Postfix community thinks about base64
> encoded emails.
>
> What is the legitimate reason to use base64 encoded emails ?
>
> Seems to me, it is only being used by spammers to complicate body_checks
>
> Would it be crazy to want to configure Postfix to not accept base64 ?
>
> I believe email should be plaintext. I don't like HTML emails either. If
> somebody feels that his message needs fancy formatting, he should send
> it as pdf attachment. But emails should stay plaintext.
>
> Hypothetically, If I wanted to block base64 and HTML, what would be the
> best way to do it ?
> At what stage in the mail delivery pipeline ?
> for 
> thanks,
>
Email Transport is not always 8 bit clean, so message that use
characters besides ASCII, (like most languages other than English will
need some extra characters) so some method needs to be used to encode
the other characters in a 7 bit way.

There are two basic encoding choices to do this, Quoted-Printable and
Base64. In Quoted-Printable every byte outside of ASCII (and the
character =) is encode as =XX (so with UTF-8 character encoding, every
no-ASCII character becomes 2-4 sets of =XX) where XX is the hex value
for the byte. This leaves the message mostly readable undecoded, but can
greatly expand the size of the message if there are a lot of non-ASCII
characters.

The other encoding is Base64 where every character in the message
encodes 6 bits of the message, so for every 3 byte of content, you
encode it with 4 ASCII characters. This makes the message always longer,
but has a much less worse case expansion.

The use of these transfer encoding can occur even for 'plain text', all
that it requires is that the character set not be ASCII, and HTML
Messages actually have their own ways to avoid needing this sort of
encoding by using HTML entities for the extended characters.

It is also quite possible that the sender didn't chose the encoding
method, and sent out the message as 8-bit (because their mail system
accepts 8-bit messages) and in the transport pipeline it got converted
to being 7 bit clean with Base64 or Quoted-Printable encoding, with the
choice being made in the pipeline.

Optimally, the encoder would chose the best encoding for a given
message, and if that as done Quoted-Printable would likely be chosen for
most message using a Latin Character language, but many encoders will
just fall back to base64 as it is simpler, and Quoted-Printable can be
very bad for some messages.

I would say that for me, I would say that a significant (maybe 10-20%)
of ordinary messages that look to be plain text, are base64 encoded, so
reject them if you are willing to lose that much legitimate email. (And
those messages are full according to the RFCs)

-- 
Richard Damon

[prev in list] [next in list] [prev in thread] [next in thread]