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

List:       postfix-users
Subject:    Re: base64 encoded emails
From:       "Bill Cole" <postfixlists-070913 () billmail ! scconsult ! com>
Date:       2019-10-17 14:17:05
Message-ID: 2B930A3D-0827-4353-AC05-FC12DA6B0D7F () billmail ! scconsult ! com
[Download RAW message or body]

On 17 Oct 2019, at 4:48, Fourhundred Thecat wrote:

> Hello,
>
> I would like to ask what the Postfix community thinks about base64
> encoded emails.

They are necessary.

> What is the legitimate reason to use base64 encoded emails ?

Any characters outside of the US-ASCII set must be encoded using Base64 
or Quoted-Printable, because it remains unsafe to assume that all mail 
transport paths are 8-bit safe. Choosing to use Base64 instead of QP is 
a reasonable decision for messages with a substantial number of 
non-ASCII characters and is simpler for the composing client, since it 
encodes all bytes in a manner that always decodes perfectly to the 
original input, while QP demands per-character judgment by the encoder 
and has corner cases where the encode/decode cycle is imperfect.

> Seems to me, it is only being used by spammers to complicate 
> body_checks

That is simply not true. It is used by some email clients as their 
default encoding for UTF-8 text and by Sendmail when it needs to pass an 
8-bit message to a mailer that isn't defined as 8-bit safe.

> Would it be crazy to want to configure Postfix to not accept base64 ?

Yes.

> I believe email should be plaintext.

I do not disagree.

There are many things in the world which should not exist but do or 
should exist but do not. Recognizing which 'shoulds' can be achieved is 
an important cognitive skill.

> I don't like HTML emails either.

I do not disagree.

I also do not like getting old. Short of terminating the process, I will 
continue to age indefinitely.

> If
> somebody feels that his message needs fancy formatting, he should send
> it as pdf attachment. But emails should stay plaintext.

General-purpose PDF has greater facility for being terrible for email 
than HTML.

This is a classic "Lost Cause" argument. The transition from strictly 
plaintext email to complex formatting and graphics in email was 
imperfect but was essential to its survival and we have the suboptimal 
result of HTML email as a de facto standard. That's the reality, and the 
world is not going to revert that change.

> Hypothetically, If I wanted to block base64 and HTML, what would be 
> the
> best way to do it ?

Shut off your mail system?

It would be trivially easy with header_checks. MIME exists to allow MUAs 
to know how to identify the nature of non-plaintext email. See the man 
page and CONTENT_INSPECTION_README.

> At what stage in the mail delivery pipeline ?

By necessity, content inspection has to happen in the second stage of 
the DATA command or after message acceptance and queueing. Rejection by 
header_checks or mime_header_checks occurs at the end of DATA.

If you want to try something more subtle, as you should, you need a real 
mail filter like MIMEDefang with or without Apache SpamAssassin. 
SpamAssassin can also be used via other milters, in a Postfix 
content_filter, or via the Postfix SMTP proxy architecture. MIMEDefang 
includes a robust MIME parser that can be used to strip MIME parts out 
and/or reconstruct them and SpamAssassin exposes the decoded and 
rendered content of Base64/HTML parts to its many filtering rules. It 
also has rule types that operate on decoded but not rendered HTML and on 
raw undecoded message data. The default ruleset included many that 
identify malformed HTML, gratuitous Base64 or QP encoding, and other 
technical quirks that correlate to mail being spam.


-- 
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
[prev in list] [next in list] [prev in thread] [next in thread]