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>
|
- Re: 2821bis AUTH48 fix (?) (was: 2821 5yz Typo - Client Retry Gaffe (fixed in 2821bis)), (continued)
- Re: 2821bis AUTH48 fix (?), Hector Santos
- Re: 2821bis AUTH48 fix (?), John Leslie
- Re: 2821bis AUTH48 fix (?), Hector Santos
- Signalling to retry RCPTs separately, John Leslie
- Re: 2821bis AUTH48 fix (?), Paul Smith
- Re: 2821bis AUTH48 fix (?), Hector Santos
- Re: 2821bis AUTH48 fix (?),
John C Klensin <=
- Re: 2821bis AUTH48 fix (?), Hector Santos
- Message not available
- Re: 2821bis AUTH48 fix (?), Bart Schaefer
- Re: 2821bis AUTH48 fix (?), John C Klensin
- Re: 2821bis AUTH48 fix (?), Tony Finch
- Re: 2821bis AUTH48 fix (?), Frank Ellermann
- Re: 2821bis AUTH48 fix (?), Tony Finch
- Re: 2821bis AUTH48 fix (?), Frank Ellermann
- Re: 2821bis AUTH48 fix (?), Bart Schaefer
- Re: 2821bis AUTH48 fix (?), Tony Hansen
- Re: 2821bis AUTH48 fix (?), Hector Santos
|
|
|