There once was a font called Smelvetica, a truly terrible prank based on Helvetica. There once was, because Monotype has sent a takedown notice for the git repo. Smelvetica was just like Helvetica except that its kerning was so bad that it was a feature. In fact, it was so bad that the font deserved a takedown notice. It deserved two.
There still exists a mail reader called Outlook, which my sort of people disliked twenty years ago, for good and bad reasons. One of the better reasons was that Outlook would implement harmful features. It still does. For example, it offers tracking pixel support, most often used via one-pixel images but Outlook offers other vectors too, including web fonts.
Bingo.
If you happen to have an old version of Smelvetica, don't like tracking pixels and suffer from a poor sense of humour, you can leverage it to send email that has terrible kerning if and only if the recipient's mail reader supports using web fonts in the way tracking needs. Here's an example of how to do it:
Date: … From: … Subject: A little gothic type Mime-Version: 1.0 Content-Type: text/html
Since Smelvetica was taken down, I chose to use
this font for the example, but the world of web fonts offers many other possibilities. Start looking here. Smelvetica was the best though — the result would look ordinary, yet somehow disturbingly wrong.
The unicode email address extensions are pleasantly simple to implement. Here is an overview of the RFCs and some notes I made while doing my first implementations; this posting is a very brief description of the protocol and format extensions involved. Despite its brevity it's nearly complete, because these extensions are so simple.
Mail message format: Using UTF8 everywhere is now permitted. Instead of using RFC2047 encoding, quoted-printable and more, messages can use UTF8 everywhere.
To: Jøran Øygårdvær <jøran@blåbærsyltetøy.gulbrandsen.priv.no> Subject: Høy på pæra Content-Type: text/plain; charset=utf8
Gørrlei av eksempler.
No encoding is necessary anywhere. Encoding is permitted but not necessary. The message above lacks From and Date, apart from that it's correct.
Sending mail using SMTP: The server advertises the SMTPUTF8 extension, the MAIL FROM command includes the argument SMTPUTF8, and the email addresses can then use UTF8.
$ telnet mx.example.com 25 Trying 2001:6d8::4269… Connected to mx.example.com […More…]
Unicode addresses in email, such as مثال@مثال.السعودية, can be written using either Punycode or UTF8. (Or, if you're feeling inventive, in another manner you invent.) Which is best?
UTF8 looks like this: From: Arabic Example <مثال@مثال.السعودية>, punycode might look like this (if it were legal, see below): From: Arabic Example <xn--mgbh0fb@xn--mgbh0fb.xn--mgberp4a5d4ar>
The answer follows from two of the design goals for the unicode email extensions:
Allow UTF8 everywhere
Extend email, don't restrict it
RFC 821 and its successors do not contain any rules such as you MUST NOT put the letter n next to an x, so Punycode is allowed. EAI allows Punycode by virtue of not forbidding what was previously allowed. But the right way is to use UTF8 everywhere. Use UTF8 in the subject field, in the body text, in the address… everywhere! That's allowed, it's a design goal, and it's better than Punycode for four reasons.
First, it's simpler than using Punycode in addresses, 2047 encoding in the subject text and qp/b64 encoding in the body text.
Second, it's very, very readable. A surprising amount of legacy software does the right thing if you send it UTF8, and that goes for humans who read email source too.
Third, Punycode's interpretation is only specified for domains, and if rumour is to be believed, people are using two incompatible encodings for the localpart. (In the example above, the second and third instances of xn-- are specified, but the first is not.) You're permitted to send a punycoded localpart to anyone, but the recipient is not required to interpret it in the way you intend and most do not.
Again, nothing in the standards requires the receiving software to understand what you mean with <xn--mgbh0fb@… The punycode example above will only work by luck.
Fourth, sending Punycode habituates users to accept random hex blobs in addresses. A phisher's dream.
So use UTF8 everywhere in the message. Mapping to Punycode is necessary when doing the MX lookup in order to transmit the message, but only then.
I've updated my list of free email providers and put it on github, removing many domains that no longer offer such services. freemail.txt contains a one-per-line list of domains that offer free email. There are also scripts to create the list.
Microsoft Exchange sends email containing a header field called Thread-Index that does much the same job as References. I've no idea why Exchange does that instead of the normal way. But I have found out how to parse it, and it's not terribly difficult. It's easiest to explain using examples, […More…]
I'm not eager to add any PGP support in Archiveopteryx. That shouldn't be needed, but is, because PGP's signature checking is much stricter than e.g. DKIM's. DKIM thinks a duck is a duck, PGP cares deeply about the details. A quoted-printable duck is not the same as a plaintext duck, and two quoted-printable ducks may not be the same either. Archiveopteryx faithfully implements sixty email-related RFCs and mail stored in or processed by aox frequently cannot be verified by PGP.
However. I care about encryption and privacy, and PGP has the mindshare and is widely considered The Solution. The problem with The Solution is that over the years, it has remained steadily at 0.0% adoption. At the moment slightly below 0.005% of email users have PGP keys, and some fraction of those 0.005% actually use PGP. I infer from that number that PGP has defects that block its adoption almost completely. I have some ideas what those defects are, but that doesn't matter, because whatever they are, their result is to block adoption.
This has been the case for 20 years, and by now I consider PGP to be hopeless. PGP hinders encryption and hurts our privacy, it doesn't help. I don't want to write any code to support that. Perhaps only ten lines of code and a few tests are needed, but I just don't want to write even that.
(Am I doing something else? Yes, I am, actually. I'll write about what later.)
Update: After writing the above, I suddenly remembered this old dystopian novel. The scenes in the 31st floor offices remind me of PGP. Worthwhile ernest people working hard, doing the best work they can.
I've implemented unicode mail three times now; in Postfix (paid for by CNNIC and not yet integrated), in aox and lastly in an old mail reader I'm porting from the Zaurus PDA to Android (unreleased as yet, send me mail if you'd like beta access). This is mostly a random collection of notes and remarks I collected while writing the code.
The specification was produced by an IETF working group called EAI (short for email address internationalisation). The WG produced two generations of RFCs. First, an experimental series which I ignore, then a revised, simplified and improved series. This covers the second generation, which takes the general position that unicode mail is only sent to recipients who understand it. There is no conversion during transport, and (almost) no fallback to ASCII.
RFC 6530 is an overview/introduction. It points to the other documents, and has some extra text. Worth reading.
6531 describes how unicode addresses are used with SMTP: MAIL FROM, RCPT TO and VRFY accept UTF8 addresses, and there's a safeguard to provoke a syntax error in case a unicode message body would otherwise reach someone who cannot accept it. […More…]
I've set up a test address for the SMTPUTF8 extension created by the IETF EAI working group.
If you send mail to jøran@blåbærsyltetøy.gulbrandsen.priv.no Jøran will send you a stock reply, which you can use to test that unicode mail works in both directions.
For the moment you must be able to send via IPv6. Jøran can send the reply back via either IPv4 or IPv6, but you have to send the initial message via IPv6. I intend to add a v4-capable secondary MX later.
I have or can arrange other testing too; send me mail if you're interested.
EAI is a set of RFCs to enable unicode email addresses. jøran@example.com and even jøran@blåbærsyltetøy.no are syntactically valid email addresses. There are RFCs to extend the email message syntax, to transmit these messages via SMTP, access them via POP and IMAP, and to provide read access by unextended IMAP/POP clients.
I wrote a set of test messages for EAI this morning and put them on github. Feel free to send me extensions and corrections.
I am sitting in Madikeri, Karnataka, India, a nice small town in the middle of picturesque forests and hills. Regrettably, the beauty of the scenery is not matched by the quality of the area's GPRS coverage. […More…]
Last year I bought a phone for Abhijit, who prefers something small and simple and couldn't find it. I could, at €17, so I ordered one and sent it to him, and have been spammed ever since. Not a problem, I can reject mail faster than […More…]