Arnt Gulbrandsen
About meAbout this blog

UIDONLY implementation notes

I implemented the IMAP UIDONLY extension in Archiveopteryx a while ago. A couple of notes:

It was really simple; two lines of code changed to six lines starting at line 1154, plus a few lines to announce the extension etc.

It didn't bring any any performance improvement, because generating the EXISTS response is mandatory. With UIDONLY Archiveopteryx counts messages in order to report how many there are in an EXISTS response. Without it, Archiveopteryx makes a list of messages. The loop is the same.

It ought to improve performance for the case where a connection opens a large mailbox and another connection already has opened that. This seems rare with Archiveopteryx. It's more important than it seems though: Opening really large mailboxes can take many seconds. I decided to leave the code in.

Implementation notes about unicode mail

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…]

Test messages for unicode mail addresses (EAI)

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.

Email address internationalisation

EAI defines a set of RFCs to provide non-ASCII email addresses. pål@eksempel.no. I looked at them with a view to implementing that in Archiveopteryx.

The good news: It's simple and sane.

The bad news: I can tell it's possible to spend a lot of time arguing about minor side issues.

IMAP, aox, 3G

A little bit of 3G first: A 3G connection is in one of several modes, ranging from PCH (which uses hardly any power and can't transfer payload data) to DCH (which uses much power and is used for bulk transfers).

The way Archiveopteryx handles IMAP, POP and SMTP is very battery-friendly. […More…]

Comments on the LWN thread

LWN ran an article on Archiveopteryx. Some points.

It's BSD-licensed, not OSL-licensed. It was OSL-licensed until last year.

One commenter opined that we might not have tested big mailboxes. Well, we have. Not sure exactly how big. We've routinely tested up to a million, bigger occasionally. At a million it's quite simple: Most mail readers fall over. […More…]

3.1.3 done

Archiveopteryx 3.1.3 is done. Finally the unending series of bugs stopped disturbing the server, and the server started running reliably, and recover from problems the way it's meant to. […More…]