Paul Smith wrote:
Hector Santos wrote:
For the record, I don't agree, not one bit with the idea
Allow Retry logic for 4yz/5yz set of RCPT/DATA reply codes
IMTO, its wrong, it earth shattering and until people can show me
otherwise (via software code, not subjective talk, not operator
options), I doubt clients will actually honor it. i.e. Most will
follow the 5yz specs and not retry.
My major concern because of this interpretation for 5yz is to begin
seeing server "thinking" they can issue a 5yz with the intent to drive
clients to perform a retry on any of their temporary rejected RCPT
commands. I really hope not because the specs already provide for all
this.
>
Can you explain how this would work?
Not sure how the question is being phrase? Are you questioning for it
or against it? How it would work when a server does issue a 5zy with
the *intent* to drive temporarily rejected RCPT?
Anyway, I think what I seeing is a lot of design implementation
assumptions that is clearly not written in the specification. More
about implementation and maybe its just a matter of common-mind
'social network' thinking a like using similar software, the behavior
is thought to be one way over another.
To me, 5zy, as it is written in 4.2.5, means one thing as whole:
- no deliver shall be expected by the sender and
no further attempt is recommended without some
out of scope user/human intervention.
I don't know how clear it can get. In short, there is no automated No
Retry strategy recommended here and that overrides the "recipient list."
Just consider the idea that one believes that 250 message acceptance
trumps the QUIT/RSET requirement for completing the transaction.
The spec says it doesn't not. Yet, you will find one argument for
this 5yz, also saying the not receiving QUIT/RSET should not discard
the message as it is written.
Go figure.
There is nothing wrong with the philosophy, but it does goes against
the specification.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com