ietf-asrg
[Top] [All Lists]

Re: [Asrg] Re: delaying response to final dot

2003-04-07 16:57:53
Claus Assmann <ca+asrg(_at_)esmtp(_dot_)org> schrieb/wrote:
On Mon, Apr 07, 2003, Claus Färber wrote:
There's no reason why it could not work in this situation: You hold off
the "OK" until you know that the message has been delivered, delivery
has failed /or/ a timeout has been elasped.

Bad Idea.

RFC 2821 already requires a "fast" response to the final dot.

   To avoid receiving duplicate messages as the result of timeouts, a
   receiver-SMTP MUST seek to minimize the time required to respond to
   the final <CRLF>.<CRLF> end of data indicator.  See RFC 1047 [28] for
   a discussion of this problem.

Well, RFC 2821 is a bit misleading here. A "fast" response to the final  
dot is not really necessary to avoid duplicate messages.
The receiving MTA can take all the time it needs to process the message  
as long as it can still abort processing. Only when the message has been  
accepted irrevocably is it necessary to send the response as fast as  
possible.

It this example scenario, only the steps marked with "|" have to be as  
short as possible.

  Sender                Receiver                Other MTA
     -- open SMTP conn. --->
    <-- env. exchange ----->
     -- DATA -------------->
     -- <CRLF>.<CRLF> ----->
                             -- open SMTP conn. --->
                            <-- env. exchange ----->
                             -- DATA -------------->
                             -- <CRLF>.<CRLF> ----->
                                            (processes message)

|                                           (wrote message to spool,
|                                           => irrevocabe)
|                           <-- DATA resonse ------
|                  (=> irrevocable)
|   <-- DATA resonse ------

It should also be noted that many modern mailers (e.g. qmail) can  
deliver a message to the next host via SMTP much quicker than sendmail  
can write it into its queue.

Further, avoiding message duplication is not an absolute requirement. A  
slightly higher probability of duplicate messages might be acceptable if  
it helps to stop spam.

What if the mail is expanded via an alias to hundreds of recipients?

An expansion counts as a delivery.

What if only some of them fail?

This problem also occurs with multiple RCPT TOs. Then you have to send a  
positive response as soon as one delivery was successful (unless you are  
using a ESMTP extension that allows to send different status codes for  
different recipients).

Claus
-- 
http://www.faerber.muc.de/
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>