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?
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.
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 mail-ot0-f179.google.com from [184.108.40.206] 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 mail-ot0-f179.google.com from [220.127.116.11] I0613 11:19:14.222302 17945 Session.cpp:295] MAIL FROM:<email@example.com> SIZE=2197 I0613 11:19:14.223953 17945 Session.cpp:346] RCPT TO:<"."@digilicious.com> 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 mx.google.com ESMTP 81-v6si3174433pfz.334 - gsmtp I0613 11:26:51.962458 31610 snd.cpp:1182] C: EHLO digilicious.com I0613 11:26:52.016620 31610 snd.cpp:475] 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 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 digilicious.com I0613 11:26:52.240614 31610 snd.cpp:475] 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 I0613 11:26:52.257822 31610 snd.cpp:1363] C: MAIL FROM:<"."@digilicious.com> SIZE=1138 BODY=8BITMIME SMTPUTF8 I0613 11:26:52.257858 31610 snd.cpp:1369] C: RCPT TO:<firstname.lastname@example.org> 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 <.@digilicious.com> 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:<"\".\""@digilicious.com> SIZE=1142 BODY=8BITMIME SMTPUTF8 I0613 11:52:26.770730 14318 snd.cpp:515] S: 250 2.1.0 OK d1-v6si2806373pgo.337 - gsmtp
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…
Apparently, amazonses.com doesn't like my cert so falls back to plain text:
I0612 08:26:10.753087 28314 Session.cpp:167] EHLO a7-22.smtp-out.eu-west-1.amazonses.com from [18.104.22.168] I0612 08:26:11.082093 28314 TLS-OpenSSL.cpp:144] no cert found for ns.digilicious.com 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 “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 22.214.171.124.
$ host digilicious.com digilicious.com has address 126.96.36.199 digilicious.com mail is handled by 15 digilicious.com.
Now, 188.8.131.52 has a few Forward Confirmed Reverse DNS (FCrDNS) names and “ns.digilicious.com” is one of them.
$ host 184.108.40.206 220.127.116.11.in-addr.arpa is an alias for 18.104.22.168.108.in-addr.arpa. 22.214.171.124.108.in-addr.arpa domain name pointer xn--ui8h.digilicious.com. 126.96.36.199.108.in-addr.arpa domain name pointer www.digilicious.com. 188.8.131.52.108.in-addr.arpa domain name pointer ns1.digilicious.com. 184.108.40.206.108.in-addr.arpa domain name pointer digilicious.com. 220.127.116.11.108.in-addr.arpa domain name pointer mta-sts.digilicious.com. 18.104.22.168.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.