I have always considered this an interesting issue and will now rant and
express my opinion at large for a couple of screens. Scroll down if you are
easily offended. ;)

Apparently nobody cares what DJB writes, which is really too bad, since I
think he is a very good author.

His maildir format is strict on output but more lenient on input, which is
a good feature for most if not all protocols.

The format specification is worth reading over and over;

"Unless you're writing messages to a maildir, the format of a unique name is
none of your business."

and

"Do not try to extract information from unique names."

and

"When you move a file from new to cur, you have to change its name from
uniq to uniq:info. Make sure to preserve the uniq string, so that separate
messages can't bump into each other."

Unique names are created by the process that delivers mail to a maildir,
for new mail, this is usually qmail-local or procmail.

For mail that is moved to a new folder, this is Binc.

The instructions for creating unique names are quite clear.

time() "." <delivery identifier> "." fixed_gethostname()

fixed_gethostname() replaces the characters / and : with the C strings
"\\057" and "\\072" respectively, in the return value from gethostname()

A modern and the old-fashioned way of constructing the delivery identifier
are both documented in the format specification.

I really don't see why this is so hard for many to follow.

procmail used to do horrendous things, like Carl originally showed us.
It has since been hacked to do something originally not allowed by the spec,
but apparently accepted later, the old-fashioned n_m delivery identifier.
procmail only handles nine or ten 'm' values correctly though, it's only one
character.

As far as I can tell, Binc creates unique names exactly like qmail-local,
with the old-fashioned n delivery identifier. While not performance
optimized (this means a fork() per mail and second or a sleep(1) per mail
when moving multiple messages) it is simply the right way, excellent work
Andreas!

On input, we all agree with DJB that Binc is a bit too strict - if you're
not writing messages to the maildir, the unique name doesn't matter as long
as it "doesn't contain a colon (or slash) and doesn't start with a dot."


On Mon, Aug 04, 2003 at 01:36:54PM +0200, Andreas Aardal Hanssen wrote:
> On Mon, 4 Aug 2003, Lukas Beeler wrote:
> 
> >> Binc IMAP skips filenames with a messed up format. Wether an application
> >> skips filenames without the required format or not, is not a part of the
> >> spec.
> >Where do you read what the required format is?
> >http://cr.yp.to/proto/maildir.html
> >States two possibilities to create a unique name.
> >Binc imapd uses neither of them, which is fine, because the name
> >just has to be unique.

Binc does use one of the described ways to create unique delivery
identifiers for use in unique names, and if not, it wouldn't have been fine.


> Nod nod nod. Binc IMAP skips these files, but it should actually record
> them. I'll add logic to the next version to handle this case better. My
> bad.
> 
> >Everybody makes mistakes ;)
> 
> Right-o. Thanks for reporting this bug and not crippling under my extreme 
> influence. ;-)

You are absolutely right about being strict when creating unique delivery
identifiers, Andreas. Kudos to you. Only the reading part is too strict.


On Mon, Aug 04, 2003 at 02:13:05PM -0400, Carl Cotner wrote:
> Well, actually, I reported the bug. :-)

Thank you, of course! :)


> I appreciate all your responses. It turns out I was using an older
> version of Procmail that was known to construct filenames of a
> different form than the examples offered in the maildir spec. So I
> upgraded to the newest version which does construct filenames similar
> to the examples, and which Binc IMAP can read.

It should work nevertheless, and will soon, as Andreas stated.


> Since this fixes the problem moving forward I decided to rename the
> files. The easiest way I found to do this was to use Mutt to tag all
> the files in a given maildir and them "save" them to the same maildir.
> In the process Mutt renames them while keeping the flags the same.

Neat trick. Yes, flags are stored outside of the unique name, so they can
easily be preserved when the unique name changes, as it does when a message
is moved between maildirs.


> Given that the maildir spec just requires uniqness, I think your plan
> to modify Binc IMAP is a good one. I've always wanted to name my
> emails in the form
> 
>   timestamp.from_address,flags
> 
> using timestamp-2, timestamp-3, etc. for possible duplicates. :-)

Doing a Microsoft, eh? :) Please follow the specification and use (or make)
a more suitable tool than your shell for working with email.

I'm starting to see why IMAP is a very good thing. The MUA shouldn't really
be dealing with how mail is stored on disk.


//Peter

In an ideal world there would be no compatibility problems, too bad there
aren't that many idealists.. :)

Reply via email to