John C Klensin wrote:
>
> <McQuilWP(_at_)pobox(_dot_)com> wrote:
>> There is no contradiction here! Only a clarification of the
>> duties of different ends of the dialog.
>
> That was certainly the intent.
I don't think that is the issue. The issue is now what does a DATA
response of 5yz means.
It means what it always has meant: That the SMTP server has refused to accept
the message. The SMTP client is required in this case not to try sending this
message to any of the recipients the server accepted again.
What you have in 2821/2821bis:
[2821/2821bis - 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. As
with temporary error status codes, the SMTP client retains
responsibility for the message, but SHOULD not again attempt
I note in passing that "SHOULD not" is bad standards-speak and needs to be
corrected to "SHOULD NOT". Otherwise this is fine.
delivery to the same server without user review of the message
and response and appropriate intervention.
And the behavior of Glen's MTA (at least as I understand it) is completely
consistent with this requirement. As is the behavior of our MTA, which is
itself the same as what I believe Glen has described.
It appears, at least with Glenn's MTA, it is assuming in a multiple
RCPT reply code scenario with DATA 5yz:
RCPT USER1 -> 250 -> DATA 5yz -> delivered
I believe Glen has stated this is not the case. If it is I agree it would be a
standards violation.
RCPT USER2 -> 450 -> DATA 5yz -> not delivered, MTA will retry.
This, OTOH, is correct. And completely consistent with the text from 2821bis
you keep quoting over and over.
The correct behavior this deliver, not deliver is when DATA is 250.
I have no idea what this means.
Am I wrong?
Yes.
I am thinking the current specs 2821 which incorrectly says is the
source of the problem:
Nope.
[2821 - 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 that message. The
SMTP client retains responsibility for delivery of that message
and may either return it to the user or requeue it for a
subsequent attempt (see section 4.5.4.1).
The originaal text is clearly inconsistent - first it talks about not retrying,
then it turns around and says a retry is permitted. The corrected text in
2821bis addresses this.
But you corrected this in 2821bis. Do people believe this current 2821
semantic is correct?
I believe the 2821bis semantics are correct. And more to the point, I believe
that our TMA is in full compliance with this semantics.
Ned