--On Saturday, April 03, 2004 15:09 -0500 Keith Moore
<moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:
I find myself wondering how valuable deferred RCPT responses
really are.
Here's why I say that: because of a race condition documented
in RFC 1047, SMTP servers should try to minimize delay between
the receipt of CRLF.CRLF to end the message and the sending of
a reply. This further implies that servers shouldn't be
waiting to actually deliver the message to recipients, running
procmail scripts, etc. before they respond. Having the
capability to report separate status for each of several
recipients doesn't eliminate the race condition.
SMTP's current design handles two kinds of per-recipient
errors:
- those are cheap to test for and can be done with the
information available at RCPT time
- those that are expensive to test for or which cannot really
be tested until after you see the message
I suppose there is a third kind - those that can be caught
on-the-fly, while the message is being received, but which due
to SMTP limitations cannot be reported until after the message
is received. Still I have to wonder how many MTAs are going
to get restructured so that all of the testing for each of the
recipients is done concurrently while the message is being
received. To do this and still minimize the potential for
races strikes me as a coding nightmare unless you seriously
constrain what kinds of criteria can be applied on a
per-recipient basis.
Exactly. See my previous note.
--On Saturday, April 03, 2004 16:36 -0600 "Eric A. Hall"
<ehall(_at_)ehsco(_dot_)com> wrote:
On 4/3/2004 2:09 PM, Keith Moore wrote:
Here's why I say that: because of a race condition documented
in RFC 1047, SMTP servers should try to minimize delay
between the receipt of CRLF.CRLF to end the message and the
sending of a reply.
The current draft model deals with this by immediately
returning a 353 response code (or any other valid response,
such as 250/550) after the end-of-data sequence.
Any additional delays that would be incurred from per-user
inspection of the content would come after that immediate
response.
Eric, the reason for the "minimize delay" rule isn't "time to
deliver first response" it is "time until the transaction can be
closed out and the queue entry removed. The RFC 1047 race
condition is somewhat reduced by "first response" because the
sender knows the receiver got the content, but it isn't enough.
If there is even a vague possibility of getting a "4yz recipient
<xxx> is out to lunch, try later" message -- and there certainly
is in your scenario -- then the sender may need to requeue the
message for that recipient, which prevents closing out the
transaction.
john