ietf-smtp
[Top] [All Lists]

Re: 2821bis/ter and procedures (was: Re: retry question)

2008-08-08 06:50:35


>>   MAIL FROM:<a>
>>   250 ok
>>   RCPT TO:<b>
>>   250 ok

Sorry, I misread this as a 5yz in my previous response. The case where there
are no valid recipients is very different, and an error response to the data
means no recipients should be retried.

I should also point out that if there are no valid recipients the
client probably sohuld not have bothered to send the message.

>>   RCPT TO:<c>
>>   450 try later
>>   RCPT TO:<d>
>>   550 no such user
>>   DATA
>>   blah blah
>>   .
>>   554 ugh

>> Which, if any, of b, c, and d get retried?  Why or why not?  What if
>> the 554 were a 450?
>
> My take FWIW, is that none should be retried because the data is
> rejected (probably based on content analysis e.g. spam or
> virus). If the data response were a 450, a+b+c should be retried.

Yep, that's my (revised) assessment as well.

But 554 can mean all sorts of things.  Maybe it was a content failure,

That's a legitimate use of a 554 code.

maybe there was some screwup storing the mail.

This, OTOH, sounds like a temporary error to me - a case where use of 554
would be inappropriate. But if a 554 is used, the client should honor it
even if the server is being silly.

Or let's say it was a 552
which can mean mailbox full.  Now what?

I presume you're refering to the RFC 821 bug that misclassified 552 as a
temporary error. If so, then that oddball case only applies to RCPT TO
responses.

Like I said, this gets really twisty.

If you don't read carefully, as I just failed to do, sure. But as long as you
pay attention I don't think this is all that tricky. The fact that servers can
and sometimes do send ill-advised responses to the client is not an excuse for
clients attempting to second-guess what the server really should have sent.

                                Ned