Gjermund Sorseth <gjermund(_at_)nextra(_dot_)com> writes:
...
HOWEVER: the fact is that several other programs, user agents and IMAP
servers with which procmail must interoperate, do parse the filenames.
I know of two reasons:
1) Sort the messages according to the time they were delivered by
sorting them by filename (since the first item in the name is
a timestamp)
Unfortunately, it's the _wrong_ timestamp: it's the time seen by the
_client_ at the _start_ of delivery. If you want the actual delivery
time (when the message was moved from the tmp dir to the new dir), you
need to check the mtime on the file instead. Shell scripts can easily
do this by using "ls -t" instead of "ls".
Any program that thinks the time included in the filename is useful is
wrong.
2) Code the file size into the filename so that it is quicker to
find the total size of a maildir later. Instead of stat'ing every
message one needs only to read the directory, parse the filenames
and add up the sizes. The Courier mail system uses this. Very useful
and resource-saving if you use NFS mounted mailboxes. The name of
a file with size 3067 bytes will for example be:
96243352.4366.mailhost,S=3067:2,
You gotta love a standard, except when it isn't. The size information
should have been placed _after_ the colon, using a registered format.
As is, a program written to use that information may break when used
with any other maildir software. Thus do local extensions break
portability.
A ",S=3067" has been added just before the colon. I highly recommend
that procmail change its Maildir file naming scheme to match the rest
of the world, even though I feel that procmails present behaviour
Would that be qmail or Courier?
does not violate the `standard'. This will make it less painful for mail
admins to use procmail as their local delivery agent and thus contribute
to raise procmails popularity.
The maildir standard was a great idea, but it was poorly worded and now
we see the result: poor interoperability. I will change procmail if
and when a clear maildir standard is written. Until then it's just
groping in the dark.
Personaly, as an administrator of a large mail system, I would very
much like to see number 2) above be implemented in procmail.
Or perhaps even better - let the user choose the format by optionaly
supplying procmail with a format string in /etc/procmailrc, for example:
MAILDIRNAME = "%time.%pid.%host,S=%size"
The danger of such a variable, combined with its costs, would far
outweigh its benfits. Indeed, source hacking would be required to add
any new % expansions, so what's the benefit of making it configurable?
Backwards compatability with broken software which requires the old
format. Wow, maildir is such a great standard.
Philip Guenther
Procmail Maintainer
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail