Many email providers support Unicode in mail.
Those that do not at this time confound me; Apple (me.com,mac.com,icloud.com), Y! (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?
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 [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 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
On November 1st 2022 and most days before that, my "USPS Informed Delivery Daily Digest" mail came from an IP address assigned to the United States Postal Service. Those message had correct text/plain parts. On the 2nd day of November I started receiving those messages from IP addresses assigned to Mailgun Technologies Inc. Other clues that the messages were sent from Mailgun include X-Mailgun-XXX type headers.
The messages sent via mailgun all had what looked like double Content-XXX headers in the text/plain parts.
Maybe nobody is looking at the text/plain part of messages anymore, and especially with these USPS messages where the image of the mail pieces is the most important information.
--32174a49fffb98655c1a5b304c5c33542cb7c8983f22eb971a53514c7bad
Mime-Version: 1.0
Content-Type: multipart/alternative;
boundary="b00e814b3e56a7c3070a1b6e4203d22cbe3814226b6892b6f9efcfa3e5bd"
--b00e814b3e56a7c3070a1b6e4203d22cbe3814226b6892b6f9efcfa3e5bd
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
Content-Type: text/plain; charset=3DUTF-8
Content-Transfer-Encoding: 7bit
Informed Delivery(TM)
Today's Deliveries: 03/16/2024
Notice that the second set of content-type headers are transfer encoded as quoted-printable.
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.