I was trying to figure out how to implement the UIDL command as part of a POP3 daemon I am building using Node.js. UIDL is an optional command in RFC 1939, but many POP3 clients use it in the leave-message-on-server scenario to determine which messages have been read. The problem, of course, is when mbox is used as there is no part of the message that can be used to uniquely identify a message.
Dovecot provides a heuristically-decent mechanism. They use MD5 to hash the following headers:
- The first Received: header
- Delivered-To: header
First Received header should be unique but there are cases where that may not be so. Aliases are an example: emails sent to an alias would not have a globally unique Received header. Dovecot solves this problem by adding X-Delivery-ID to the hash, but that only works for messages that have this field (the existence, which by definition, is optional).
I was contemplating using Message-ID as RFC 2822 specifies that Message-Id is unique, but uniqueness here refers to the body, not the headers. Hence, a single message to CC’ed to 10 people would have the same Message-ID. Not quite unique, as RFC 1939 requires:
The unique-id of a message is an arbitrary server-determined string, consisting of one to 70 characters in the range 0×21 to 0x7E, which uniquely identifies a message within a maildrop and which persists across sessions.
Even though POP3 RFC specifies that duplicate messages (not just the body, but headers as well) are a problem the client needs to deal with, I thought some rigor in the server implementation would have been nice. However, that doesn’t seem to be possible and as such, I implemented Dovecot’s original strategy of Received and Delivered-To headers.