Glenn Anderson wrote:
At 9:37 pm -0400 9/8/2008, Hector Santos wrote:
John Levine wrote:
Which, if any, of a, d, and r get retried? Why or why not? What if
the 554 were a 421 or 451?
DATA 554 trumps them all. No Retries for this transaction.
There are actually 3 transactions, one for each recipient. The 554
response to the DATA command only applies to the transactions that
haven't already been rejected or delayed.
That is not what 2821/2821bis says in 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.
This applies to single or multiple RCPT list, rejected or otherwise.
It doesn't make the distinction because its a flat out non-acceptance
for all.
If we changed this, in order to be technically correct at the protocol
state machine level, then we have to go back to the meanings of the
RCPT reply code for 250:
RCPT 250 - no matter what DATA says, the mail will be delivered.
In other orders, we made the decision at the point, before even seeing
the data, that this user will ALWAYS get the mail.
That is fundamentally wrong and doesn't fit even in the SINGLE RCPT
transaction model:
C: RCPT TO: B
S: 250 OK
C: DATA
S: 354 continue
... payload transferred ...
S: 550 Message not accepted for delivery
C: QUIT
Does user <b> still gets the message? I don't think so. Clients do
not, not technically and I should say, legally have no "user
expectation" for delivery here. Rejection was satisfied, technically
and legally. No basis or claim of censorship can made made.
What is being suggested is that this fundamental acceptance, rejection
concept now changes when two or more RCPT are used:
C: RCPT TO: B
S: 250 OK
C: RCPT TO: C
S: 450 OK
C: DATA
S: 354 continue
... payload transferred ...
S: 550 Message not accepted for delivery only for B, not C
I really don't think that is how the state machine works. In other
words, clients are not expecting this. It doesn't make sense.
Rejected when its a single RCPT, but accepted for a Multiple RCPT
situation?
I think part of the problem is that we have two modes of operations
and thinking that the industry was using but now more and more
shifting to:
OLD MODEL - Accept ALL - does post SMTP delivery decisions
NEW MODEL - Does dynamic SMTP level delivery decisions.
Of course, the old model, mostly used in larger systems for
scalability reasons, was and still is highly prone to the massively
abusive Accept/Bounce/Spoof problems.
In the name of security, addressing this massive accept/bounce/spoof
problem and just better/faster resolution of acceptance/rejection
status notification, the industry is shifting toward dynamic SMTP
decisions which for larger systems, does requires high end software
and hardware to satisfy the scalability requirements.
In the old model, you accept all, and make this individual decisions.
Maybe the problem is that old model thinkers believes the new model
works the same way?
Yes and No.
Yes, it does if the Tony Finch original concern was considered.
No, when the client decides it was a one shot deal - ala possibly a
news mailing list.
Off hand, overall to get the old model back into the new model, if we
rewrite the meaning of RCPT 250 and DATA 55x.
This is why we provide the option in our mailing list server software
to either distribute using the 1 transaction for multiple RCPT or
using a split of 1 transaction per recipient. The latter improves the
delivery for temporarily down recipients.
If this is not the case, then indeed, it goes on to explain why we
have serious issues for clients mainly but also for servers who has to
bear the burden of clients not following a long time solid state
machine and fundamental principle.
If it was the case, then you would have an inconsistency between what
would happen if the same 3 transactions were handled individually.
Right. See above.
But again, this is exactly what the original issue was with Finch's
comment. Mail is accepted for some (a DATA 250), but there exist a
few 450 RCPT. How does a client handle that?
All I am saying is that before we can make this work, you have to
begin with the DATA 250 as all the SMTP documents old and new say.
This will allow you to continue the deliver for the accepted RCPT and
then allow the client to decide how to handle the temporarily rejected
ones.
But overall, if a DATA 55x is provided, the server is not going to
deliver for any of the supplied RCPT, and the client should really
stop trying because this payload "that message", as 2821bis puts it,
was simply not acceptable.
Anyway, I hope this issue was maybe a matter of the old 2821 text that
as corrected in 2821bis and it is now a moot point.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com