[plug] moving mail in postfix

[Daniel Pittman]

Russell Steicke <russellsteicke at gmail.com> writes:
> On 4/24/09, Daniel Pittman <daniel at rimspace.net> wrote:
>> Russell Steicke <russellsteicke at gmail.com> writes:
>>> On 4/17/09, Daniel Pittman <daniel at rimspace.net> wrote:
>>>>...
>>>> What, like that they are a dreadfully poor implementation of mh folders
>>>> that aims to address one locking related issue that is no longer hugely
>>>> relevant, and do so mostly by wishful thinking?
>>>
>>> What is the wishful thinking you're referring to here?
>>
>> The algorithm DJB describes for delivery is faulty in at least two
>> cases, revolving around the "lockless" nature of maildir.
>>
>> One is that renaming messages while a readdir operation is in progress
>> can, in practice, cause them to be omitted from the value returned to
>> the calling program.
>>
>> This can cause concurrent operations on the maildir to cause a message
>> to briefly vanish, then reappear; since the filename contains message
>> flags this is not an uncommon operation.
>
> This is something that I haven't seen mentioned before, and it sounds
> like a potential problem.  I can't say that I've seen it in practice.

With luck, most IMAP-on-Maildir implementations, and most mail clients,
shouldn't see it.  OTOH, back when the htree code for speeding directory
searching was introduced to ext3 there were a significant number of
programs that did get caught out by this issue.

IIRC, the change meant that it could skip files if a tree rebalance
happened during readdir, or so.


>> The other is the delivery process, in which the implementer is
>> instructed to construct a filename, stat it, then sleep two seconds
>> if there was a file found.
>>
>> That races against the next operation, which is to create the file in
>> .../tmp/ inside the maildir, where two processes could concurrently
>> generate the same filename, receive a negative answer from stat and then
>> try to create the same file.
>
> This is overcome by using guaranteed unique information in the file
> name: timestamp, host and process id.  He does mention that it is
> possible for a host to recycle PIDs within a second, but very
> unlikely.

Well, the race is avoided by using that technique, but the race is still
present and is documented as correct and, more importantly, useful
behaviour.

Also, yes, the *valuable* part of the protocol is "generate a unique
name", with the rest being ... mostly there to look good, really. ;)

> Have you seen this create name collisions in practice?

>From Maildir delivery software?  Not that I know of, but the sensible
stuff works around this with locking anyhow.  I have seen this sort of
unique name generation code fail in production, however, on other
systems that also looked convincingly random on paper.

>> The same problem happens in the next step, where you link(2) the file
>> from tmp to new, since renaming from new to cur could race with that
>> and cause a duplicate delivery.
>
> Ditto with the unique information in the file name.

*nod*  So, you would agree that the Maildir delivery protocol is mostly
bunk and, in truth, depends only on the generation of an assuredly
unique filename for successful delivery?

> I think you should bear in mind that djb spec'd Maildir a few years
> ago (13 or 14 off the top of my head) and NFS delivery was much more
> common then, and locking over NFS was then very unreliable.

Oh, I am keeping that in mind, indeed.  I said, in fact, that most of
the problems it sets to solve are no longer relevant, since technology
has improved in the area. :)

Did I mention that NFS exacerbates these "time of check, time of action"
issues, by the way?  Makes them much easier to hit, because of the
asynchronous and potentially delayed nature of a response to a request.

> Only a couple of years after that, I was regularly losing mail as it
> was delivered into mh mail directories, and was very glad to find
> Maildir, which has never lost me any mail.  (IIRC, the mh man pages
> warned about the possibility of losing mail with concurrent access.)

*nod* mh requires locking.  So, for real security, does Maildir,
although it is more likely to work in practice since the races require
uncommon conditions and are thankfully unlikely to be hit anyhow.

I am surprised that your network administrators had incompatible locking
schemes configured for mh, however.  Most people managed to get that
right back in the days it was a serious contender, by virtue of
administering a distributed mailstore being a fairly skilled job.

> You've mentioned that NFS locking is fixed, but in my case, I've been
> bitten by it being unreliable too often to trust my mail with it.  To
> be clear: NFS is fine; trusting locks over NFS is not.

*nod*  Personally, I wouldn't be so generous to NFS, but I don't
disagree with your statement.


So, no, Maildir isn't without benefit, but I don't feel you have really
touched my contention that it mostly solves problems that have gone
away, or that most of the delivery protocol is there to look good.

Regards,
        Daniel