ietf-smtp
[Top] [All Lists]

Re: Improved straw man for retry scenarios

2008-08-10 05:31:07

At 7:54 am -0400 10/8/2008, Hector Santos wrote:
Lets try to pin this down. I would like to ask this question since you indicated your MTA behaves this way (correct me if I mis-read you).

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.

Q2 - If A or B, is this based on the presumption DATA response will change? Eventually?

As user2 was delayed, the DATA response at the time is simply not applicable. The DATA response could be different when user2 is subsequently retried and not delayed.

Q3 - Do you believe that because USER1 was 250, the Server SHOULD not issue a negative response?

No.

(To help with robust principle?)

I don't see how that has anything to do with robustness.

Glenn.