Today I was testing an option for long Postfix queue IDs (queue
file names) that won't be reused for about 30+ years. The idea is
to prepend the 30 least significant bits of the time in seconds to
the queue ID.
For the long queue IDs I chose an encoding that packs more bits in
a queue ID character. As a result, long queue IDs are typically
only four characters longer than old queue IDs. Where old queue
IDs use characters from 0-9A-F (4 bits per character, i.e. base 16
encoding), my first implementation of long queue IDs used characters
from 0-9A-V (5 bits per character, i.e. base 32 encoding).
The reason for using this base 32 character set was that it is
compatible with Postfix's queue file name syntax checks, unlike
base 64 which uses non-alphanumerics. This is helpful if you want
to back out a change and go back to an older Postfix version, and
not have all hell break loose because it rejects all the new queue
files.
Here is an example of the prototype logging:
Mar 12 17:10:13 tail postfix/pickup[22915]: 6NNRQ6SKNI58V5S: uid=D from=<AAAA>
Mar 12 17:10:13 tail postfix/cleanup[22921]: 6NNRQ6SKNI58V5S:
message-id=<20110312221013.6nnrq6skni58...@tail.porcupine.org>
Mar 12 17:10:13 tail postfix/qmgr[22916]: 6NNRQ6SKNI58V5S:
from=<a...@porcupine.org>, size=328, nrcpt=1 (queue active)
Mar 12 17:10:14 tail postfix/smtp[22923]: 6NNRQ6SKNI58V5S:
to=<aaa...@porcupine.org>, orig_to=<AAAAAA>,
relay=spike.porcupine.org[2001:240:587:0:2d0:b7ff:fe88:2ca7]:25, delay=0.07,
delays=0.02/0.02/0.01/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
EEBB01F3E90)
Mar 12 17:10:14 tail postfix/qmgr[22916]: 6NNRQ6SKNI58V5S: removed
So far so good. Unfortunately, writing a secure mail system involves
more than avoiding coding errors.
The problem is that the larger alphabet and longer queue IDs increase
the possibility that existing words will appear inside queue IDs
(consider that the letters C, F, K and U are in the base 32 alphabet
and that a queue ID can be 12 characters long). Even non-profane
words may cause distraction. Real words can also appear with base64
encoding of message body parts, but most people aren't directly
exposed to such information, so it is less of a problem.
One solution is to eliminate the vowels (AEIOU) from the encoding,
and to add one other character (or keep the A which was already
used in old queue IDs) so I can keep packing 5 bits into each queue
ID character. Another option is to use some encoding that is not
a nice power of 2.
Whatever the final implementation will be, I expect that support
for long queue IDs will be disabled by default, at least initially.
Wietse
