>
> 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.
I do not
think the third column of the second line is correct.
I agree, and have given examples in previous messages of existing server
behavior will cause an unwarranted delivery failure.
I am not
inferring any relation between RCPT and DATA which is why I would
argue against using the above chart.
I confess to some ambivalence about this.
...
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.
Ned