Mail in the 3rd millennium

My hopes for email

Unicode

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

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

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:

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 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.

C: MAIL FROM:<"\".\""@digilicious.com> SIZE=1142 BODY=8BITMIME SMTPUTF8
S: 250 2.1.0 OK d1-v6si2806373pgo.337 - 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; and not in keeping with all the RFCs 822, 2822, and 5322.

Mailgun.com'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, amazonses.com doesn't like my cert so falls back to plain text:

EHLO a7-22.smtp-out.eu-west-1.amazonses.com from [54.240.7.22]
no cert found for ns.digilicious.com
error:140943F2:SSL routines:ssl3_read_bytes:sslv3 alert unexpected message
fatal OpenSSL error

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

$ host digilicious.com
digilicious.com has address 108.83.36.113
digilicious.com mail is handled by 15 digilicious.com.

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

$ host 108.83.36.113
113.36.83.108.in-addr.arpa is an alias for 113.112.36.83.108.in-addr.arpa.
113.112.36.83.108.in-addr.arpa domain name pointer xn--ui8h.digilicious.com.
113.112.36.83.108.in-addr.arpa domain name pointer www.digilicious.com.
113.112.36.83.108.in-addr.arpa domain name pointer ns1.digilicious.com.
113.112.36.83.108.in-addr.arpa domain name pointer digilicious.com.
113.112.36.83.108.in-addr.arpa domain name pointer mta-sts.digilicious.com.
113.112.36.83.108.in-addr.arpa domain name pointer ns.digilicious.com.

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 “digilicious.com” 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