On 2007-04-13 10:07:19 -0400, John Leslie wrote:
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.
If one side violates a MUST clause, we are IMHO out of the scope of
defined behaviour, unless the spec explicitely defines some error
behaviour. (Which RFC 2821 in general doesn't, unless I've missed it:
For example, what happens if a client sends a command with more than 512
characters, or a bare LF in data? The RFC doesn't say, some servers will
issue an error message, some will accept it, and some (badly written)
servers will crash or behave weirdly in some other way)
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.
The bug is IMHO that it isn't completely clear whether all codes in a
multiline reply must be the same. Hector interpretes the current text to
mean that they can be different, while several other (including me)
interprete it to mean that they must be the same.
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
I would go for "the server MUST make all the codes the same" here. Is
there anything to be gained from this ambiguity?
At most I would add a warning that an extension could allow different
codes in multiline-replies.
Also, must the reply codes be exactly the same?
Consider something like:
251 Forwarded to <foo(_at_)example(_dot_)net>
IMHO, the server should know it will forward by the time the first
line is issued.
I wasn't suggesting that it's a particularly bright idea for a server to
return that kind of message, but it's one of the edge cases which should
be considered once one starts to standardize behaviour in case of
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hjp(_at_)hjp(_dot_)at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"
Description: Digital signature