Change default MTA was Re: Fedora Core 2 wishlists
mrsam at courier-mta.com
Fri Dec 12 00:05:18 UTC 2003
Chris Ricker writes:
> On Wed, 10 Dec 2003, Sam Varshavchik wrote:
>> Chris Ricker writes:
>> > On Wed, 10 Dec 2003, Ronny Buchmann wrote:
>> >> If MDA and MUA try to access it at the same time, you run into problems when
>> >> they don't agree on a locking scheme or when using NFS.
>> >> Maildirs don't need locking.
>> > Not true. That's why what passes for the Maildir standard was revised
>> > earlier this year, after people found out the hard way that the "locking
>> > not needed" hype was losing their email....
>> I'm not aware of Bernstein doing anything like that.
>> If you're referring to adding milliseconds to the filename, nothing in the
>> revised naming convention requires any kind of locking whatsoever. I'm not
>> sure where that notion came from. Sounds like the usual suspects have been
>> spraying FUD again.
> I'm not saying it required locking, I'm saying one reason the revision was
> needed was due to lack of locking.
No, it was due to filename collision.
If you had some kind of locking in place you'd still have the same exact
window of vulnerability, except that you would've had to have a slightly
faster CPU/disk before you get nailed.
> Look at why the file naming was revised
> -- PID recycling was causing non-unique filenames w/in a second, which in
> turn lead to collisions.
And how exactly would some kind of a locking mechanism change that?
> One way of looking at that is that the original
> Maildir convention was fine to still use with locking as protection against
There was no locking in the original convention.
> The other way of looking at it is that the original standard
> was broken and truly unique filenames should have been chosen instead. As it
At the time, nobody was recycled PIDs in less than a second. In fact, there
were some VERY good reasons AGAINST doing so; because it would've broken
And I still believe that recycling PIDs in this fashion is a dumb idea. The
explanation is that randomized PIDs improve “security”. Yes, but at the
same time you've just opened up a bunch of new holes.
> happens, djb changed the standard (though I don't think qmail got
No, and I'd be surprised if he ever does anything with Qmail again.
> Similarly, what can happen when you mix products which implement Maildirs
> differently (ie, Postfix LDA does something like time.device#inode#.hostname
> now, while Mutt appears to still do something more like time.pid.hostname
> for the uniqueness in filenames)? Shouldn't locking be needed there?
There's an established filename creation convention. As long as everyone
follows the same set of rules -- which provide a GREAT deal of leeway --
there's no collision. Even the older format, used by mutt, is not a problem
because the collision could only occur if mutt terminates and its pid get
recycled in the same second. The filename collision is only an issue for
mail delivery agents, which get forked, unload a single message, and exit.
It's not an issue for mail clients.
The updated filename generation convention does provide for a format that
includes the device and the inode. Since the dev/ino tuple is always
unique, there's no chance for a duplicate filename; and as long as the
actual format used by Postfix follows the convention, it won't conflict with
anything else that uses the same convention.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20031211/75d544c8/attachment-0002.bin
More information about the devel