ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:
>
> DATA
> +----------------------------------------------+
> | | 250 | 45x | 55x |
> |--------+-----------+------------+------------|
> | 250 | DELIVER | MAY RETRY | NO RETRY |
> RCPT |--------+-----------+------------+------------|
> | 45x | MAY RETRY | MAY RETRY | NO RETRY |
> |--------+-----------+------------+------------|
> | 55x | NO RETRY | NO RETRY | NO RETRY |
> +----------------------------------------------+
You are using a "MAY RETRY". It is more of a MUST here.
I was with up to this point. I agree MAY RETRY is too weak, but MUST
RETRY goes too far because it ignores both context and local policy.
> For example, if after some number of days you're still getting that
> 4yz on repeated attempts, returning the message is entirely
appropriate.
SHOULD RETRY is a better fit IMO.
+1, I was trying to keep within 72 columns <g>
I'm not pushing any new idea.
Nor am I. The examples I've given where following these are behavior
servers are known to exhibit and which is specifically called out in
> a full standard RFC.
If I may try to summarize the issues, it begins with the batter of two
modes of operations:
- Old Model of Post SMTP delivery/bounce decisions,
- New Model of SMTP level dynamic Acceptance/Rejection,
and a Retry Logic that hopes make both the old and the new "behave"
the same.
IMV, I thought Finch's input was par for how to help make the new
model work as it did with the old model. It requires clients to take
450 RCPT responses in multiple RCPT transactions and retry them.
But that presumes nothing else changes, i.e. it always begins with a
DATA 250 response - not a DATA 55x.
The only explaination for this mindset is this 8 year old gaffe in RFC
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).
which was fixed and corrected in 2821bis:
When an SMTP server returns a temporary error status (4yz)
code after the DATA command is completed with <CRLF>.<CRLF>,
it MUST NOT make a 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 2821 version was simple a typo with the 5yz code. The correction
in 2821bis is reflective of the current framework.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com