Pete Resnick wrote:
On 8/10/08 at 3:55 PM -0400, Hector Santos wrote:
Take the following example:
S: 220 foo.com Simple Mail Transfer Service Ready
C: EHLO bar.com
S: 250-foo.com greets bar.com
S: 250-VRFY
S: 250 HELP
C: MAIL FROM:<Smith(_at_)bar(_dot_)com>
S: 250 OK
C: VRFY Jones(_at_)foo(_dot_)com
S: 250 <Jones(_at_)foo(_dot_)com>
C: RCPT TO:<Jones(_at_)foo(_dot_)com>
S: 250 OK
C: VRFY Green(_at_)foo(_dot_)com
S: 250 <Green(_at_)foo(_dot_)com>
C: RCPT TO:<Green(_at_)foo(_dot_)com>
S: 450 Can't send to him right now
C: DATA
S: 354 Start mail input; end with <CRLF>.<CRLF>
C: Blah blah blah...
C: ...etc. etc. etc.
C: .
S: 250 OK
C: QUIT
S: 221 foo.com Service closing transmission channel
So, the message was delivered successfully to Jones(_at_)foo(_dot_)com(_dot_)
According to 4.2.5 above, since Green(_at_)foo(_dot_)com exists, and foo.com
(the server) has sent back a 250 to the DATA command, foo.com (the
server) now has responsibility for delivering the message to
Green(_at_)foo(_dot_)com (retrying if necessary) and bar.com (the client) SHOULD
NOT attempt to retry delivery to Jones(_at_)foo(_dot_)com(_dot_) Is this the correct
interpretation?
Unless I am not see the "ah ha" in your example, in my technical
opinion, it is exactly what it means.
OK, I suspected this was Hector's interpretation. As Ned pointed out,
there is general consensus that 4.2.5 does *not* mean that and never
did. It has also been amply demonstrated here by several folks that the
damage done (in terms of lost mail) by interpreting it Hector's way is
far greater than the converse. If there are others who read it the same
as Hector (and more importantly, implemented it that way), it is
important that we document that this is not correct. Either way, it's
probably worth writing a document explaining this for beginners.
For the archive record, I disagree.
Beginners are the eventual victims and IMO, 2821bis needs to get out
quickly, so that it can help correct an ill-course that was taken with
the 2821 4.2.5 gaffe.
Since you had one Mulligan, I deserve one too addressing the above.
Let keep this simple because it really is that simple:
First, the server issued a 250 for DATA <EOT>. That means acceptance
for DELIVERY, and it applies to:
Jones(_at_)foo(_dot_)com
only.
Second, since there is RCPT 450 for Green(_at_)foo(_dot_)com, and there is a DATA
<EOT> 250, you are allow to retry it.
Look at this from thea pure POST SMTP delivery decision method where
you always accept first - all replies are 250, the session is
gracefully close and some post smtp router/bot makes delivery
decisions. In this case,
Mail is delivered for Jones(_at_)foo(_dot_)com
Mail is bounced for Green(_at_)foo(_dot_)com
The key distinction is that there was an important resolution in all
cases.
In the POST SMTP model, you had one delivery and one bounce.
In the DYNAMIC model, you had one delivery and one pending that the
client is still responsible for - but NOT the server.
The original issue is whether the client is going to retry or not.
From the specs standpoint, he is allowed to retry. So here is
nothing broken there. But you can't force him to retry - thats a
different issue.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com