Tim Legant <[EMAIL PROTECTED]> writes:

> If including the hostname in the pending filename implies we must
> also include it in the confirm address, I don't like it.

It does imply this, else we couldn't locate the right pending file on
disk when a confirmation arrives.

> I don't think we gain anything from it and it's just additional
> complexity.

The only gain is that it guarantees there will never be a name clash
when writing a pending file to disk. Without this, although unlikely,
if two machines are delivering to TMDA during the same second and with
the same Python process ID, there will be a clash.

However, now that I look at Util.writefile(), I see that it raises an
IOError if the requested destination already exists. So, I don't think
this will be a problem. In the above scenario, the IOError would defer
the message which tried to write second, and next time the queue is
run, it will have a new timestamp and pid, and so no more clash.

I think a deferral in the unlikely event of a filename collision is
acceptable since it should not happen very often (if at all). An MTA
such as qmail probably can't afford this luxury since it would
decrease delivery performance, but I think we can.

So, the new pending queue will be a ``Maildir-compatible'' structure
rather than a true Maildir since it doesn't use gethostname() for the
third portion of the filename.
_________________________________________________
tmda-workers mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-workers

Reply via email to