Peter J. Holzer <hjp-ietf-smtp(_at_)hjp(_dot_)at> wrote:
On 2007-04-12 16:44:01 -0400, Robert A. Rosenberg wrote:
At 15:20 -0400 on 04/11/2007, Tony Hansen wrote...
(iii) Prohibit different codes and, optionally, suggest
that it is ok for a client to select one of them and
assume that all of the others are the same.
Also, I do not like the optional "Pick One" authority in iii.
That follows directly from the requirement that all codes MUST be the
same. If they are the same, it obviously doesn't matter which one the
client uses. If they are not the same, the server is violating the spec
and the client can do what it wants.
The server would indeed be violating the spec.
It does not follow that a cient may do what it wants.
We're discussing a bug (IMHO) in 2821 which allows, in the case of
multiline replies to DATA (phase 2), different clients to have different
views of whether the message was accepted for delivery.
I, at least, would like to say something like, "Absent agreement
between server and client on the meaning of different reply codes
within a multiline reply, the server SHOULD make all the codes the
same, and the client SHOULD generate an error if it receives
different codes."
you should verify that all the codes are the same and error out if
they are different.
To that extent, I agree with Robert: it should not be legal for
clients to behave non-deterministically in the presence of known
server (mis)behavior -- especially in the case where there's no
opportunity to re-synchronize.
If such a requirement is written into the RFC, it should also describe
what the the client is supposed to do in case of different codes.
Here, I agree with Peter: I'm just not sure what to recommend.
Permanent error? Temporary error?
At first blush, a permanent error seems more likely to help.
Also, must the reply codes be exactly the same?
Yes, IMHO.
Consider something like:
250-Accepting message
251 Forwarded to <foo(_at_)example(_dot_)net>
IMHO, the server should know it will forward by the time the first
line is issued.
(YMMV...)
--
John Leslie <john(_at_)jlc(_dot_)net>