Change default MTA was Re: Fedora Core 2 wishlists

[Sam Varshavchik]

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
> concurrency.

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 
some things.

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
> updated?)....

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
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20031211/75d544c8/attachment.sig>