Re: 2821bis AUTH48 fix (?)

Hi John,

<opinion bats=off final=yes rfc=off>

For me, your input makes it clear the intent for 5yz as I understood 
it, and I believe the new 2821bis corrects and codifies the intent.
I now better recognize what exist in practice for retry strategies, 
but that is an implementation concern only.
</opinion>

Thanks John for your input.

--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


John C Klensin wrote:
> --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