Please try to forgive me if you think I'm feeding the troll... Hector Santos <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
