On Fri, Jul 08, 2005 at 10:16:34AM -0700, Claus Assmann wrote:
> On Fri, Jul 08, 2005, Matthew Byng-Maddick wrote:
> [please do not Cc' me, thanks]
Please do not set mail headers that suggest you want Cc-ing, then. I
actually went back and looked at the headers of the mail you sent when
it came up with your email address in the To line. There was a
Mail-Followup-To header (which your mutt generated, and mine honoured)
with the To line in my reply.
You're welcome.
>> The important sentence in that is: "The dialog is purposely lock-step". So
>> 2821 is slightly self-contradictory, this is not news. (note that the
>> command in question is an effective null command of connection opening).
> This is only "slightly self-contradictory" if you consider connection
> opening "an effective null command" which is certainly an unusual
> interpretation and IMHO not covered by RFC 2821.
Well, I certainly consider the banner to be a reply, as it conforms to all
the syntax and semantics of a reply. (see, for example the 220, the 421 or
the 554 (S3.1)). It seems odd that the banner is treated specially - it
would be wrong, for example, to, having not negotiated PIPELINING or some
equivalent, send data out of the lock-step during the dialog, and yet somehow
the banner is not part of this. If the banner is to be treated as a reply
(and I for one think it should), then the TCP connection establishment
becomes an effective command in the dialogue. This makes sense to me.
Think about it in terms of:
S <conn establish>
S HELO im.me.com
R 220 smtp.gateway.mail.com ESMTP Mail ready
R 250 Hello, im.me.com, pleased to meet you
vs the much more obvious:
S <conn establish>
R 220 smtp.gateway.mail.com ESMTP Mail ready
S HELO im.me.com
R 250 Hello, im.me.com, pleased to meet you
(I still prefer sender and receiver SMTP)
You'll notice that in the second situation, the entire dialogue is lock-step
with an action or command, and a response to that. Now, I don't know of any
current implementation that does anything as screwed up as the reference
implementation for 821 which was why the lock-step requirement was
implemented in the first place, but I think you either need to scrap the
lock-step requirement all together, or to implement it in a consistent way.
This half-arsed "banner is not actually a response, but looks vaguely like
it" helps noone.
> BTW: please bring those "slightly self-contradictory" items up
> on ietf-smtp when RFC2821bis will be published (probably next week).
> If there's anything unclear in RFC2821(bis) then now is the chance
> to fix it.
I barely have enough time to read the lists I'm subscribed to, without
subscribing to more!! I'm sure there are other people who know more than
I do, and have more time than I currently do to raise these issues.
>> If you see violations of SHOULDs, it's also always worth asking what the
>> good reason is.
> I'm not questioning that. It's maybe just a bit "nit picking":
> the error message is misleading as it is not a _violation_ of RFC 2821.
I suspect, however, that it is a violation of STD0010, though I can't see
anything that immediately suggests it. Certainly the 220 Service ready
message is in S4.2.1 "REPLY CODES BY FUNCTION GROUPS". It describes the
banner line as a "220 "Service ready" reply" (which suggests a null
command to me), and talks about the strict lock-step nature of the
protocol. Like its successor, however, it goes on to say "The sender should
wait for this greeting....". (It predates RFC2119, obviously).
I think this point has been argued before, and I think that the
specification is self-contradictory in this regard. (2821 includes the
"Greeting" as a "reply", but it handles it entirely specially, the 220
code is also in the list in S4.2.2). As far as I am concerned, if it is
a reply in this context, then it is a reply to something, that something
is the action of opening the communication channel, and as such, the banner
is part of the lock-step protocol.
Anyone sending their hello line before they get a banner deserves everything
they get, as far as I'm concerned.
Cheers
MBM
--
Matthew Byng-Maddick <mbm@???> http://colondot.net/
(Please use this address to reply)
