First, I would like to thank everyone for the discussion of a potential RFC violation. I have noted the request and it is now on the wishlist. However, I only saw a message stating that there was an RFC violation without a discussion of the problem. Since RFC 2821 (and in similar language, RFC 821) state that IMail's current behavior is compliant (see below) it will help me to understand the request a little better. Thank you all.
"An SMTP client MUST determine its actions only by the reply code, not by the text (except for the "change of address" 251 and 551 and, if necessary, 220, 221, and 421 replies); in the general case, any text, including no text at all (although senders SHOULD NOT send bare codes), MUST be acceptable." John Korsak Product Marketing Manager, IMail Server ----- Original Message ----- From: "Sanford Whiteman" <[EMAIL PROTECTED]> To: "John Tolmachoff" <[EMAIL PROTECTED]> Sent: Tuesday, March 12, 2002 4:49 PM Subject: Re[2]: [IMail Forum] IMail's "X1" RFC violation > John, > > It is fairly common to reveal mail server vendor information in the > 220 greeting. Even security vendors will do this on their MXs (though > it's usually to show off their patch levels). > > > Since all SMTP traffic is suppose to follow the same RFC and standards, > > what does it matter as to whether or not it knows it is talking to > > another Imail server? > > Many of the technologies described in the RFCs are optional. A server > need not support all of them--but if supported, they need to be > implemented in a consistent manner. The fastest way to get information > about what services a server supports is to look at the 220, since > it's the first TCP response stream. For example, that's why vendors > put "...with ESMTP" in their 220 greetings, even though the RFCs > specify that a 250 in response to EHLO has the same meaning. > > > But why would I want another Imail server to know that it is connecting > > to my Imail server? > > I think it's quite reasonable to have this information available for > proprietary interconnects such as peering. The problem is that you > can't turn it off! Instead of demanding that Ipswitch take out the X1 > entirely, which is unreasonable, how about demanding that it be > optional and put at the end of the greeting if it's enabled. If AOL or > anyone else starts to check for RFC compliance, a fix is going to have > to be made available instantly, so it should be fixed now while > there's still time for regression testing. > > I've also found that all peering needs is *a* 220 X1 ESMTP line, not > necessarily the first one. So the easiest fix, still > backward-compatible, would be to just put the proprietary tag on the > second line, and have the first line be RFC. > > Sandy Please visit http://www.ipswitch.com/support/mailing-lists.html to be removed from this list. An Archive of this list is available at: http://www.mail-archive.com/imail_forum%40list.ipswitch.com/ Please visit the Knowledge Base for answers to frequently asked questions: http://www.ipswitch.com/support/IMail/
