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 <[EMAIL PROTECTED]> http://colondot.net/ (Please use this address to reply) -- ## List details at http://www.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://www.exim.org/eximwiki/
