Mail in the 3rd millennium

My hopes for email


I continue to hope for wide support of Unicode in mail.


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

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

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

Problems with major email providers

Issues with Google's mail receiving

Apparently gmail doesn't like receiving mail from addresses with a quoted string in the local part. It seems to strip them out and then report an error if the local part is no longer a valid address. Gee, maybe that's why I quoted it.

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:

I0613 11:19:13.641806 17945 Session.cpp:167] EHLO from []
I0613 11:19:13.836145 17945 Session.cpp:909] STARTTLS version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128 verified
I0613 11:19:13.897742 17945 Session.cpp:167] EHLO from []
I0613 11:19:14.222302 17945 Session.cpp:295] MAIL FROM:<> SIZE=2197
I0613 11:19:14.223953 17945 Session.cpp:346] RCPT TO:<".">
I0613 11:19:14.238674 17945 Session.cpp:779] BDAT 2197 LAST
I0613 11:19:14.238770 17945 Session.cpp:780] message delivered, 2730 octets, with id 5nm6iyuacamrq
I0613 11:19:14.298413 17945 Session.cpp:839] QUIT

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

I0613 11:26:51.962446 31610 snd.cpp:465]  S: 220 ESMTP 81-v6si3174433pfz.334 - gsmtp
I0613 11:26:51.962458 31610 snd.cpp:1182] C: EHLO
I0613 11:26:52.016620 31610 snd.cpp:475]  S: 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
I0613 11:26:52.016651 31610 snd.cpp:1241] C: STARTTLS
I0613 11:26:52.066087 31610 snd.cpp:515]  S: 220 2.0.0 Ready to start TLS
I0613 11:26:52.190671 31610 snd.cpp:1249] C: EHLO
I0613 11:26:52.240614 31610 snd.cpp:475]  S: at your service, […]
                                          S: 250-SIZE 157286400
                                          S: 250-8BITMIME
                                          S: 250-ENHANCEDSTATUSCODES
                                          S: 250-PIPELINING
                                          S: 250-CHUNKING
                                          S: 250 SMTPUTF8
I0613 11:26:52.257822 31610 snd.cpp:1363] C: MAIL FROM:<"."> SIZE=1138 BODY=8BITMIME SMTPUTF8
I0613 11:26:52.257858 31610 snd.cpp:1369] C: RCPT TO:<>
I0613 11:26:52.312630 31610 snd.cpp:1429] C: BDAT 1138 LAST
I0613 11:26:52.364876 31610 snd.cpp:515]  S: 553-5.1.2 The sender address <> is not a valid RFC-5321
                                          S: 553 5.1.2 address. 81-v6si3174433pfz.334 - gsmtp
I0613 11:26:52.364893 31610 snd.cpp:734]  C: QUIT

This same “MAIL FROM” address works fine with every 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. Now why would they do that? Oddly, 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 result.

I0613 11:52:26.716012 14318 snd.cpp:1363] C: MAIL FROM:<"\".\""> SIZE=1142 BODY=8BITMIME SMTPUTF8
I0613 11:52:26.770730 14318 snd.cpp:515]  S: 250 2.1.0 OK d1-v6si2806373pgo.337 - gsmtp 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; and not in keeping with all the RFCs 822, 2822, and 5322.'s MX records point to google. This always seems like a red flag for companies in the email space. We're email experts, but we don't trust ourselves to run our own email infrastructure. Yeah, I get the argument: why waste any time on something that is not core to ones business? I have a few counter arguments…

Issues with Amazon's mail sending

Apparently, doesn't like my cert so falls back to plain text:

I0612 08:26:10.753087 28314 Session.cpp:167] EHLO from []
I0612 08:26:11.082093 28314 TLS-OpenSSL.cpp:144] no cert found for
W0612 08:26:11.254812 28314 TLS-OpenSSL.cpp:844] error:140943F2:SSL routines:ssl3_read_bytes:sslv3 alert unexpected message
W0612 08:26:11.255326 28314 TLS-OpenSSL.cpp:845] fatal OpenSSL error

So what's odd is they are asking for a cert for “” But why? The email they're attempting to deliver is for domain “” which has an MX record that points to “” which has an A record that returns

$ host has address mail is handled by 15

Now, has a few Forward Confirmed Reverse DNS (FCrDNS) names and “” is one of them.

$ host is an alias for domain name pointer domain name pointer domain name pointer domain name pointer domain name pointer domain name pointer

But so what? Amazonses seems to (randomly?) select one of these names then throws a hissy fit when the cert I present doesn't match that name.

The cert I use has a Common Name (CN) of “” and some Alt Name Extensions for a few of the other FCrDNS names listed. But not, apparently, the one they want.

I will also point out that this is a Let's Encrypt issued cert that should pass a traditional PKI check. I also publish TLSA records for my certs, so a DANE check should also validate the cert.

So they are strangely fussy about my cert, but happily reconnect in plain text to then send the mail.

Update: I just added every name to the cert, why fight?

Apparently, Mimecast doesn't like my certs either. Not sure why. They, too, ask for a hostname based on a random PTR record, not sure that's a problem. The don't list lets encrypt as a supported authority, so maybe that's the issue. I reported the problem to them, but they say they can't even look into it beacuse I am not a customer.

Valid HTML 5