On Wed, Mar 28, 2001 at 04:36:20PM +0000, Mark Delany wrote:
> > The first one is correct. The second one does not follow djb's rules
> > for naming the file. If procmail wrote it, your version of procmail is
> > broken.
All versions of procmail are broken, IMHO :)
> I disagree. To quote from the webpage: "A unique name can be anything
> that doesn't contain a colon (or slash) and doesn't start with a
> dot.".
>
> On that basis, the procmail filename is fine. Sure the webpage goes on
> to *suggest* one method for generating unique names, but there is no
> suggestion that that is the only way.
>
> One could argue that procmail is being smart by ensuring that the
> unique namespace it uses can only possibly collide with itself.
One could also argue that procmail is being dumb by defining an
'abnormal' namespace. Another package defining an 'abnormal' namespace
may use a completely different algorithm, that generates the same
string as procmail does at *another* moment. Voila, a clash.
Also note that procmail makes no effort *at all* to check if it's
replacing an already-delivered mail. If something clashes, tough luck.
Therefore, procmail can lose mail (and I have heard suggestions that
procmail's algorithm doesn't guarantee uniqueness, even, but I haven't
verified that).
> > > How are these random names generated?
>
> Anyway the MDA wants. The primary requirement is that it be
> unique. You should not infer any meaning beyond uniqueness for
> everything before the colon.
But uniqueness can only be guaranteed by consensus!
procmail's Maildir implementation is (even ignoring this uniqueness
problem) almost guaranteed to *lose* mail. It neglects to implement
several of the Maildir requirements.
To my knowledge (from extensive sourcecode reading) only qmail-local
and safecat 1.5 and up implement Maildir correct *and* acceptable.
(Len owes me beer for the diff between safecat 1.4 and 1.5 :)
Disclaimer: I have not looked at all maildir implementations yet. I
have looked at procmail's, and it is heavily inadequate.
Greetz, Peter.
