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.
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 & Quoted-Printable encoding and decoding of binary email content? Does it approach that of the hash calculations made for Bitcoin mining?
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.
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 typically is text that is added to explain the MIME formatting and is expected to be shown in mail reading software that does not support MIME.
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 addresses, 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 [188.8.131.52] STARTTLS version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128 verified EHLO mail-ot0-f179.google.com from [184.108.40.206] MAIL FROM:<firstname.lastname@example.org> 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:<email@example.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 all the other email service providers 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
The popular (bulk) email sending service mailgun never sends the QUIT command in a mail transaction. They just disappear. Which, I guess, doesn't seem to negatively impact their ability to send mail. It just seems rude to me; not in keeping with RFC-5321.
Mailgun.com's MX records point to google.