Please try to forgive me if you think I'm feeding the troll...
Hector Santos <hsantos(_at_)santronics(_dot_)com> wrote:
Not even Hector doesn't support Hector's proposed text. :-)
Hector can be rather hard to follow...
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
There's an example: after the fourth attempt to read it, I gave up.
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.
We _all_ need to understand that software _will_ do whatever it can
get away with. We can't control that: we can only say what complies
with a standard and what doesn't (_if_ we could agree among ourselves).
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.
This statement deserves a specific response.
Server software _can_ issue a 5yz response. We can't stop this.
Some client software obviously interprets this that way (or the
server software to do that wouldn't be getting deployed).
Hector seems to think this is bad. No doubt _someone_ agrees with
him. That's not the point.
Server software tries things like this because some folks think
there _should_ be a way to tell the sending SMTP client to try the
recipients separately. Right now, the only fully supported way is to
enforce a limit of _one_ recipient (which is explicitly deprecated,
BTW, and probably drives some client software into bugland).
I think we're within a few orders of magnitude ;^) of consensus
that it would be nice to standardize a better way. But we've never
come close to consensus on a _particular_ better way.
I really hope not because the specs already provide for all
this. The proper signal is 4yz or if the server is going to accept at
least 1 RCPT, then use 250. In both cases, the specs allow the client
to retry the temp rejected RCPT.
Most of us have long given up on religious wars about which signal
is "proper".
It's an implementation decision how to treat responses not covered
by the spec. It _must_ remain so. Some implementors will be utterly
convinced they have found the magic incantation to accomplish something
outside the spec. The next day, other implementors will be just as
convinced some other magic incantation does the trick.
Most of us will say, "That's nice..." to both groups, followed by,
"So what?" under our breath. We mean no disrespect -- we just have
too many other brush-fires burning.
--
John Leslie <john(_at_)jlc(_dot_)net>