Mail in the 3rd millennium

“Modern” email

Unicode

Many email providers support Unicode in mail.

Those that do not at this time confound me; Apple (me.com,mac.com), Oath (yahoo.com,aol.com,aim.com), Fastmail, ProtonMail, and some others.

CHUNKING

Why such slow adoption of CHUNKING in the free (software) world?

Of course, CHUNKING is a step towards BINARYMIME. What is the carbon footprint of all the pointless base64 encoding and decoding of binary email content? Does it approch that of the hash calculations made for Bitcoin mining?

End to end

I hope someday for end-to-end encryption in email, perhaps using the OpenPGP message format or any other reasonable technical solution.

I have high hopes for Autocrypt.

My MTA supports TLS. Please use certs that can be validated, either PKI style or DANE.

Intersting quirks of major email providers

Hotmail rewrites your HTML

HTML messages sent to Hotmail (and apparently other Microsoft email services) are content-transfer decoded, modified, and then re-encoded.

For example, if I send a message with a body like so:

    
<!DOCTYPE html>
<html lang=3D"en">
  <head>
    <meta charset=3D"utf-8">
    <title>title</title>
  </head>
  <body>
  <p>
I'm going to place '.' characters at the end of each sentence=
. And another=
. And yet another=
.
  </p>
  </body>
</html>

If I fetch the received message using my IMAP client, the body has been transformed into this:


<!DOCTYPE html><html lang=3D"en"><head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8">
    <title>title</title>
  </head>
  <body>
  <p>
I'm going to place '.' characters at the end of each sentence. And another.=
 And yet another.
  </p>
  </body>
</html>
.

I think I mostly understand this. The original body is quoted-printable decoded; then the HTML is modified to include the extra http-equiv meta tag which is set to the values in the message headers; then the body is quoted-printable encoded once again. There are other minor differences in whitespace and line endings, as you might notice.

The DKIM signature is validated before this transformation takes place, and results included in a Authentication-Results: header. Of course, if your email client later attempts to validate any signatures it will fail, as this is no longer the original body.

The only part I don't understand is that extra “.” (Full Stop) character at the end. It's after the closing </html> tag but the Hotmail web interface shows it at the end of the message. There are four Full Stop characters in the original body, and five after it hits the Hotmail inbox.

The other modification I see with Microsoft is the removal of any text before the first multi-part MIME boundary. This text is added to explain the MIME formatting and is expected to be shown in mail reading software that does not support MIME.

Google “MAIL FROM” address syntax

Apparently gmail has some issues receiving “MAIL FROM” addresses with a quoted string in the local part. They seem to strip the quotes out and then report an error if the local part is no longer a valid address.

They can send mail to such assresses, but when you try to send them mail from such addresses, they balk.

Sending from gmail is fine. An excerpt from my logs:


EHLO mail-ot0-f179.google.com from [74.125.82.179]
STARTTLS version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128 verified
EHLO mail-ot0-f179.google.com from [74.125.82.179]
MAIL FROM:<gene.hightower@gmail.com> SIZE=2197
RCPT TO:<"."@digilicious.com>
BDAT 2197 LAST
message delivered, 2730 octets, with id 5nm6iyuacamrq
QUIT

But sending to gmail is not okay. Some lines from my logs:


S: 220 mx.google.com ESMTP 81-v6si3174433pfz.334 - gsmtp
C: EHLO digilicious.com
S: 250-mx.google.com at your service, […]
S: 250-SIZE 157286400
S: 250-8BITMIME
S: 250-STARTTLS
S: 250-ENHANCEDSTATUSCODES
S: 250-PIPELINING
S: 250-CHUNKING
S: 250 SMTPUTF8
C: STARTTLS
S: 220 2.0.0 Ready to start TLS
C: EHLO digilicious.com
S: 250-mx.google.com at your service, […]
S: 250-SIZE 157286400
S: 250-8BITMIME
S: 250-ENHANCEDSTATUSCODES
S: 250-PIPELINING
S: 250-CHUNKING
S: 250 SMTPUTF8
C: MAIL FROM:<"."@digilicious.com> SIZE=1138 BODY=8BITMIME SMTPUTF8
C: RCPT TO:<gene.hightower@gmail.com>
C: BDAT 1138 LAST
S: 553-5.1.2 The sender address <.@digilicious.com> is not a valid RFC-5321
S: 553 5.1.2 address. 81-v6si3174433pfz.334 - gsmtp
C: QUIT

This same “MAIL FROM” address works fine with most other email service provider I have tried: Yahoo, Hotmail, Apple, etc.; and software: Sendmail, EXIM, Postfix, MeTA1, etc.

Notice that in the server's reply the quotes have been stripped out. If I include the double quotes inside the quoted string as quoted pairs they seem fine with that. Presumably they strip the outer quotes and accept the address if the stripped result is, by itself, a valid address.


C: MAIL FROM:<"\".\""@digilicious.com> SIZE=1142 BODY=8BITMIME SMTPUTF8
S: 250 2.1.0 OK d1-v6si2806373pgo.337 - gsmtp

C: MAIL FROM:<"\" = Gene Hightower = \""@digilicious.com> SIZE=1274 BODY=8BITMIME SMTPUTF8
S: 250 2.1.0 OK k92si6271664otc.125 - gsmtp

mailgun.com never QUITs

The popular (bulk) email sending service mailgun never sends the QUIT command in an mail transaction. They just up and disconnect. Which, I guess, doesn't seem to negatively impact their ability to send mail. It just seem rude to me; not in keeping with RFC-5321.

Mailgun.com's MX records point to google.

Valid HTML 5