ietf-smtp
[Top] [All Lists]

Re: 2821bis AUTH48 fix (?)

2008-08-12 10:34:33



--On Tuesday, August 12, 2008 12:10 AM -0400 Hector Santos <hsantos(_at_)santronics(_dot_)com> wrote:

...
Anyway, I think what I seeing is a lot of design
implementation assumptions that is clearly not written in the
specification.  More about implementation and maybe its just a
matter of common-mind 'social network' thinking a like using
similar software, the behavior   is thought to be one way over
another.

To me, 5zy, as it is written in 4.2.5, means one thing as
whole:

     - no deliver shall be expected by the sender and
       no further attempt is recommended without some
       out of scope user/human intervention.

I don't know how clear it can get.  In short, there is no
automated No Retry strategy recommended here and that
overrides the "recipient list."

Hector,

I'm probably repeating what others have said, but what the document is intended to say, and has said since Jon Postel introduced the state machine model, is something like the following for the sorts of transactions you are talking about. I want to go through this to be sure that, if we are not on the same page, we are sure that we disagree. And, to the extent that I have some responsibility as editor, I want to make my own understanding clear. I hope that neither you nor anyone else will take this as a request or excuse to repeat or restart the discussions of the last several days.

S: 220 Example.com SMTP service ready
    (no recipient buffer, no mail transaction)
C: EHLO i-am-a-client.example.net
S: 250-...
S: 250 ...
    (still no mail transaction, no recipient buffer)
C: MAIL FROM:<fubar(_at_)example(_dot_)net>
S: 250 Sender accepted at least so far
    (mail transaction started, no recipient buffer)
C: RCPT TO:<a(_at_)example(_dot_)com>
S: 250 recipient ok, I think.
    (recipient buffer contains "a(_at_)example(_dot_)com")
C: RCPT TO:<b(_at_)example(_dot_)com>
S: 450 better luck next time
    (no change to recipient buffer, still just "a(_at_)example(_dot_)com")
C: RCPT TO:<c(_at_)example(_dot_)com>
S: 550-No, and do not bother trying again
S: 550 unless you know something has changed
    (no change to recipient buffer, still just "a(_at_)example(_dot_)com")
C: RCPT TO:<d(_at_)example(_dot_)com>
S: 250 recipient ok, I think
(recipient buffer now contains "a(_at_)example(_dot_)com, d(_at_)example(_dot_)com")
C: DATA
S: 354 Send message body
C: blah blah
C: blah blah blah
C: .

Now, anything the server says at this stage relates to the message content or to delivery to "a" or "d". "b" and "c" don't count -- they never made it into the recipient buffer, and the difference between the 4yz and 5yz codes is between the server advising the client to retry and the server essentially forbidding such a retry unless there is some user intervention or substantive out of band reason to believe that circumstances have changed a permanently undeliverable state to something else. Any server sending back a 4yz or 5yz code in response to a RCPT command is outside the spec.

A 2yz response to RCPT can, however, mean any of the following:

   (i) I like the address and will deliver to it.

   (ii) I like the address and will deliver to it unless there
   is a space problem for the account in the mail store or some
   other constraint that does not depend on analysis of the
   message body is violated (e.g., a SIZE failure).

   (iii) I like the address and will deliver to it if I feel
   like it after analyzing the message body, consulting various
   oracles, etc.

The second and third of these are viable iff one is willing to return NDNs. The first, given a bunch of edge cases and race conditions is really either a variation on (ii) or (iii) or is not meaningful in practice.

Now the server has to respond to the DATA command (which includes the message body). If it responds with a 2yz code, then it has assumed responsibility for delivery to every address in the recipient buffer (and no others). That responsibility can be discharged only by delivering the message to a mail store (or portion thereof, or equivalent) that is nominally under the control of the addressee or by issuing an NDN. One might or might not like that, but it is what the spec has [IMO always] said.

If it responds with a 4yz code, it is expecting the client to retry, someday, with the same set of recipients as it found in the recipient buffer. That means "a" and "d"; once again, "b" and "c" are irrelevant. In general, that would be a dumb response unless there has been, e.g., a failure in the mail store itself because that language about not issuing 4yz codes and delivering anyway means that, if delivery has already occurred to "a" and a temporary problem is found with "d", the MTA is expected to either un-deliver to "a" or to issue a 2yz code and keep retrying "d" locally (or sending back a d-specific NDN). 4yz responses at this stage are also out of the spirit of trying to move mail forward through the system. And that is precisely why the 4yz codes that are listed as appropriate responses to DATA are only 421, 451, and 452 (which was really intended to mean what the description says -- "system storage"-- not "mailbox full") and not 450, which does have to do with individual mailboxes.

And, if it replies with a 5yz code, that is a definitive rejection although, again, only for the entries in the recipient buffer. If that isn't what is wanted, then the server should not be issuing a 5yz code at that point. And, to repeat myself again, as far as the server is concerned, the only difference between a 4yz code and a 5yz one is the difference between "go away and try later" and "go away and don't come back". Attempts to read more subtle clues into any of this, or to apply heuristics about what was intended or why the rejection occurred, will just lead to interoperability problems, surprises, and trouble. I know that people don't like NDNs, but they are exactly what the model expects for these cases.

If one wants anything else, then I think the right path is some sort of per-recipient reply extension, either the one Hall proposed a while back, or something else. But I don't see much point in discussing it without an active draft on the table.

If there is consensus that it what the text says, and agreement that it needs clarifying (a need strong enough to risk getting into a "well, you changed _that_, so why not change _this_" debate), then I would welcome specific textual suggestions for 2821ter if it ever happens.

   john


<Prev in Thread] Current Thread [Next in Thread>