Arnt Gulbrandsen
About meAbout this blog

The one-minute guide to implementing unicode email addresses

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­>
Subject: Høy på pæra
Content-Type: text/plain; charset=utf8

Gørrlei av eksempler.

No encoding is necessary anywhere. 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 25
Trying 2001:6d8::4269…
Connected to
Escape character is '^]'.
220 ESMTP Postfix (3.0.0)
ehlo myhostname

mail from:<> smtputf8
250 2.1.0 Ok
rcpt to:<jøran@blåbærsyltetøy­>
250 2.1.5 Ok
354 End data with .

Note that the EHLO argument is sent before the client knows whether the server supports SMTPUTF8. It's best to use ASCII-only EHLO arguments.

The SMTPUTF8 argument to MAIL FROM has two purposes: Notify the mail server that one or more addresses may contain UTF8, and make sure that the recipient software does not receive a message it will not be able to parse.

Thus, if you send a message to आर्न्ट@यूनिवर्सल.भारत with a cc to and the mail software at does not support SMTPUTF8, then only आर्न्ट@यूनिवर्सल.भारत will receive the message. The mail server for will reject the message. This is intentional.

An MTA needs to do an IDN conversion (e.g. from blåbærsyltetøy­.­gulbrandsen.­ to xn--blbrsyltety-y8ao3x.­gulbrandsen.­ as part of MX lookup, a client that connects to its local server doesn't need even that.

Access using IMAP: The server advertises the ENABLE extension, the client sends ENABLE UTF8=ACCEPT (that's legal even if the server advertises only ENABLE), the server acknowledges having enabled UTF8=ACCEPT, and from that point, both server and client can use UTF8 for any quoted string, including folder names, search strings and addresses.

$ telnet 143
Trying 2001:6d8::6942…
Connected to
Escape character is '^]'.
a login arnt pils
b enable utf8=accept
b OK done
c select "Gørrlei"

Testing: Gmail supports this, both for SMTP, IMAP and webmail. The jøran@… address is an autoresponder, you can send mail to it and will receive a reply in a few seconds. Blåbærsyltetøy means blueberry jam and includes all of the three special letters used in Norwegian, æ, ø and å, so it's often used as a test word.

There are more details, but this is 90% of what's needed to write a correct implementation.

Using procmail as an autoresponder

Procmail is old and almost forgotten, but still works well. This short script is the autoresponder for jøran@blåbærsyltetøy­

:0 c

* !^X-Loop:
* !^Auto-Submitted:
| (formail -r -t -I"From: Jøran Øygårdvær " -A"Auto-Submitted: auto-replied" -A"Mime-Version: 1.0" -A"Content-Type: text/plain; charset=utf8" -A"Content-Transfer-Encoding: 8bit" ; echo "Liker du blåbærsyltetøy? Jeg synes blåbærsyltetøy er veldig godt." ; echo ; echo "-- " ; echo "Jøran") | /usr/sbin/sendmail -t

The first clause stores all incoming mail in /tmp/jøranmail just in case it's needed for debugging. The second clause filters out three kinds of mail that should not receive an autoreply. For messages that pass all three hurdles, it runs formail with many arguments to create an EAI-compliant autoreply header, echo to write a brief reply, and sends the result back.

It may not be terribly readable, but it's brief and reliable. That glass is two thirds full, not one third empty.

A new email address

I think mail to आर्न्ट@यूनिवर्सल.भारत should now land in my inbox... wonder how long it'll take before the first spammer manages to spam that address.

Three programs, one feature

It's not something one does often, but I've implemented the same feature in three different programs. Not very different, all are written in the same programming language for the same platform, and all are servers.

Same platform, same language, same task, same developer... you would think the three patches would end up looking similar? They did not, not at all.

The feature I wrote is is support for using UTF8 on SMTP, which I've implemented for Postfix, Sendmail and Qmail, which all run on linux/posix systems. I tried to follow the code style for each of them, and surprised myself at how different my code looked.

One patch is well-engineered, prim and proper.

The next is for an amorphous blob of software. The patch is itself amorphous, and makes functions even longer that were too long already. Yet it's half as long as the first patch. The two are, in my own judgment, about equally readable. One wins on length, the other on readability, they're roughly tied overall. This surprised me not a little.

The third is a short, readable patch which one might call an inspired hack. It's a much smaller than the others and easily wins on readability too.

It wasn't supposed to be like that, was it? Good engineering shouldn't give the most verbose patch, and the hack shouldn't be the most lucid of the three.

I see two things here:

First: Proper engineering has its value, but perhaps not as much as common wisdom says. Moderately clean code offers almost all of the value of really clean code.

Second: A small program is easy to work with, such as the MVPs that are so fashionable these days. But ease of modification isn't all, the smallest among the three servers has fallen out of use because the world changed and it stopped being viable.

Some random verbiage on each of the three servers and patches: […More…]