Clients are not expected to behave as the Ned's Software does for the
5yz DATA <EOT>.<EOT> response. It is clearly written in the basic
SMTP specification.
PROBLEM:
If the SMTP sender-client is going to react to 5zy with SHOULD RETRY,
then conversely, then it is expected that SMTP Receiver-Server will be
issuing the same 5yz responses with the intent to drive the clients in
such manner.
I strongly suggest that this is not the NORM. This will cause lost of
mail and it contradicts 22+ years of legal User Expectations molded by
the US EPCA for delivery and/or notifications for rejection.
EXPLANATION FOR BEHAVIOR:
There is good explanation for the behavior, that sadly enough no one
thus far has yet wish to acknowledge, that for eight years, RFC 2821
4.2.5 had it written that 5yz DATA <EOT>.<EOT> responses do allow, in
fact, encourage (SHOULD) client retries.
This error was noted and corrected in 2821bis.
What Klensin, Hansen et al, need to decide if they revert to the
previous 2821 broken semantic because it appears to be some MTA (at
least one MTA - Neds) that were already trained with this behavior.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Frank Ellermann wrote:
John C Klensin wrote:
[substantive]
If someone wants something else, it is probably time to dust
off and finish some flavor of per-recipient post-DATA reply
model and see if it gets any traction.
It's not that I want "something else", but getting some kind
of "selective reject" on standards track could be good. That
could also contain any desired "retry clarification", as far
as this "clarification" does not try to redefine RFC 2821bis.
[procedural]
if you expect me to do it quietly during AUTH48,... well,
there is no chance.
IFF Hector - nobody else is in his position - could propose
less than ten words ASAP that would settle this issue from
his POV, and confirm what most others (SM, Glen, Ned, etc.)
here said, *and* IFF these folks agree with his proposal,
then I'd hope you can still add this - openly, not quietly.
For obvious reasons I'd like to get 2821bis in a state where
it can be promoted to STD in 2009 "as is", without new draft:
The chances might be slim, but if nobody finds fresh errata,
2821bis could officially replace RFC 821 in STD 10 next year.
Frank