<ned+ietf-smtp(_at_)mrochek(_dot_)com> wrote:
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.
That's another call for "please fix the NOT":
<http://article.gmane.org/gmane.ietf.smtp/7481/match=auth48>
I'm not sure how "fine" it is, Hector's and your (among others)
interpretations are clearly different.
Hector appears to be mostly out on his own here. AFAICT SM, Pete, all three
Johns, Glenn, Tony F, Robert, and myself are all in basic agreement as to what
constitutes correct behavior.
To the extent we disagree, it is about ancillary stuff like to what extent a
client is oliged to retry in the various retry cases.
Maybe it is irrelevant,
Hector's interpretation only misses an opportunity to "retry".
On the contrary, Hector's interpretation causes lots of legitimate email to
fail to be delivered in the VERY common case of pipellning to a single
temporarily over quota recipient. This is hardly a minor matter.
(With disk prices as low as they are and with Gmail and others offering huge
mailbox sizes, you'd think that over quota conditions would be rare, but the
fact of the matter is this is far and away the most common error case we see,
so much so that we've gone to a huge amount of effort to optimize its handling
in various ways.)
Where KISS (his 3*3 table) and "the mail must flow" principles
conflict I'd bet that Hector would prefer "the mail must flow",
but this could mean "change critical code at its core".
I don't believe Hector has said how his MTA behaves, but mine and Glenn's both
behave the way I believe is correct. In my case at least the "change critical
code at its core" approach would be to adopt Hector's position.
Ned