I would like to get a feel from our MTA developers and operators what
they feel about this below:
Glenn Anderson wrote:
>> Suppose your MTA was connecting to our server, and you were sending
>> mail to 3 accounts and the RCPT reply codes was:
>>
>> RCPT TO: user1 ---> 250
>> RCPT TO: user2 ---> 450
>> RCPT TO: user3 ---> 550
>>
>> because there was at least one 250, you were allowed to go to DATA
>>
>> DATA
>> 354 continue
>> ... payload transfered ...
>> 550 not accepted.
>>
>> With the 550 DATA server response,
>>
>> Q1 - How will your MTA behave here?
>>
>> A) continue to try USER1?
>> B) continue to try USER1 and USER2?
>> C) not continue to try any?
>> D) Other scheme?
>
> D, continue to try USER2, as that transaction was delayed.
That what our MTA does as well - DSN for USER1 and USER3, continue to retry
USER2.
Glenn's answer assumes USER1 will be getting the message here.
I don't believe that's correct.
I believe the correct answer is C.
Nope, and several examples have already been given showing why it isn't
correct.
It matches the specifications:
[2821/2821bis - 4.2.5]
When an SMTP server returns a permanent error status (5yz) code
after the DATA command is completed with <CRLF>.<CRLF>, it MUST
NOT make any subsequent attempt to deliver the message.
But this doesn't apply to USER2 or USER3 since neither were accepted as message
recipients. It only applies to one recipient that was accepted: USER1, and
AFAIK nobody has gone with A on your list.
As
with temporary error status codes, the SMTP client retains
responsibility for the message, but SHOULD not again attempt
delivery to the same server without user review of the message
and response and appropriate intervention.
I hope that others can chime in one way or another because we are
talking about changing the specifications if other systems behave as
Glenn's MTA.
I disagree that this is a change.
Ned