Pavel Kankovsky <[EMAIL PROTECTED]> wrote:
> On Thu, 10 Feb 2000, Len Budney wrote:
>
> > Any MTA which returns success before writing a message to the
> > filesystem, and syncing it, should be thrown away...
>
> What if the MTA has already forwarded the message in question to other MTA
> and got an acknowledgement? What if the message has already been processed
> by some program? Why should MTA bother making sure a copy of the message
> has been saved to the disk in these situations?
In those situations, storing a copy on disk would not be necessary, of
course.
I'd be fascinated to know whether that's _ever_ a good idea. In the
situations you describe, the MTA _must_ stall the sender until it
finished processing the message.
If the MTA is forwarding via SMTP, then senders will typically suffer
a delay of over ten seconds. If the MTA is filtering through a
program, then senders will suffer an unpredictable delay which can
easily be manipulated by a malicious recipient.
(Now imagine a mail which makes several hops, and suppose that each
MTA in the chain stalled the caller while forwarding the message.
Gack.)
As an added bonus, you get all the code bloat which goes into deciding
whether to forward, filter or queue messages.
> Qmail's design has advantages but it is not the only way to design
> MTA in the universe.
Zeroseek promises an improvement <http://cr.yp.to/qmail/future.html>,
so qmail's _exact_ strategy is not the only one--even in Dan's opinion.
The examples which you gave don't look like viable alternatives, though.
Len.
--
Good ciphers are designed by good cryptanalysts.
-- Bruce Schneier
