Matthias Andree writes:
The problem strikes when one of the following is true:The problem strikes when stuff is moved from new/ to cur/ again, as has been shown for mutt (note this is also what DJB's reply about maildir_scan() was about). See my response to Felix.
1) Maildirs are read by applications that do not use the same exact logic that maildir_scan() uses. And it should be mentioned again that there does not appear to be any reference the additional check in maildir_scan() in any official or semi-official documentation for maildirs or qmail, as far as I know. There seems to be a completely different reason why qmail-pop3d does this, djb is just pretending that this was the intent right from the beginning :-)
2) NFS. Even the maildir_scan() logic will not eliminate the race condition when NFS is in the picture, due to client/server clock skew. Even with ntpd, I get a skew of 0.02 seconds on a completely unloaded 10BaseT lan, with a sub-millisecond ping time. So, it seems to me that there's almost a 0.02 second's worth of a race condition where a file can be created on the NFS server, that the server will timestamp at T-1, with respect to the client's clock. That is 0.02 seconds, minus the software overhead. Cut it in half, it's still 0.01 seconds. And busy systems, that deliver hundreds of thousands of times a day have hundreds of thousands of opportunities to hit the jackpot. When they do, this is no longer a theoretical discussion, because maildir_scan() will not stand in the way of the race being fully exploited, as long as the remaining dominoes will fall into place.
I strongly recommend that someone should patch Qmail to add tv_usec to maildir filenames, when delivering mail. I did this to Courier, I think someone needs to do this to Qmail.
**********
From: Matthias Andree <[EMAIL PROTECTED]>
Subject: Re: OpenBSD 3.2 breaks Courier, Qmail.
Date: Wed, 15 Jan 2003 22:31:57 +0100
[ ... ]
Thanks for saving me the trouble of replying to Felix. I doubt that I'd be as patient, or polite.Scenario, phor tha thtoopid:1. qmail-local delivers via tmp/1042665948.12345.hermes to new/1042665948.12345.hermes 2. MUA (not qmail-pop3d) moves new/1042665948.12345.hermes to cur/1042665948.12345.hermes,2:S=4444 or something 3. same second, PID reuse(*), qmail-local writes to tmp/1042665948.12345.hermes. qmail-local link(2)s that file to new/1042665948.12345.hermes
I should point out that even another MUA, in step #2, is not necessary if NFS is used.
Did I dream all those countless and countless amounts of web.ink, extolling the virtues of Maildirs over NFS??? Did I imagine all of that?
So, with NFS, and clock skew, you have a definite, non-zero, chance of hitting the jackpot even with with qmail-pop3d, since when you hit the jackpot, qmail-pop3d thinks the mail was delivered a second earlier. See above.
