IMail Forum, I'll leave the technical discussion to the programmers of the list to argue about the MUSTs, SHOULDs and WILLs in the RFC.
I would like to mention that modifying the greeting is now on the list of planned changes for the next major release. I just want to reiterate that this is a planned change and it depends on how development progresses. John Korsak Product Marketing Manager, IMail Server ----- Original Message ----- From: "Sanford Whiteman" <[EMAIL PROTECTED]> To: "Eric Shanbrom" <[EMAIL PROTECTED]> Sent: Wednesday, March 13, 2002 2:26 AM Subject: Re[4]: [IMail Forum] IMail's "X1" RFC violation > Eric, > > Ain't this fun? We're like the Win32 Slashdot. :))) > > You have it that... > > > according to the RFC one will not refuse mail if the reverse lookup > > doesn't match. You can perform it but must still accept the mail > > irregardless of the match. > > ...but in RFC 2821, 4.2: > > > In particular, the 220, 221, 251, 421, and 551 reply codes are > > associated with message text that must be parsed and interpreted by > > machines. In the general case, the text may be receiver dependent > > and context dependent, so there are likely to be varying texts for > > each reply code...Since, in violation of this specification, the > > text is sometimes not sent, clients which do not receive it SHOULD > > be prepared to process the code alone (with or without a trailing > > space character). > > Note *in violation of this specification*. As in many RFCs, to ensure > "proper" operation of the Internet, i.e. not everything breaks at > once, breaking the server-side specification *may* be tolerated by the > client. But it doesn't have to be. And it is still a violation on the > MTA, even if the MUA looks the other way. (Also in classic RFC form, > the specific is stated before the general--like they've got DNS on the > brain.) > > Later on in RFC 2821, 4.2: > > > 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. > > I read this as reiterating that 220 is an *exception* to the MUST and > is thus not subject to the general case. So a client is *not* obliged > to act as if a blank 220 greeting is okay, if it is "necessary" to > treat the text as useful information--like if it's checking for > non-compliant servers in an effort to combat spam. > > Re: the X1 as illegal domain name specification (even leaving aside > the concept of whether it must match the PTR or any other RR for the > server) here's RFC 2821, 4.3.1: > > > Note: all the greeting-type replies have the official name (the > > fully-qualified primary domain name) of the server host as the first > > word following the reply code. > > And earlier in RFC 2821, 3.6: > > > Only resolvable, fully-qualified, domain names (FQDNs) are permitted > > when domain names are used in SMTP. > > X1 is to be considered the domain part of the 220 reply, but it > doesn't comply with the RFC requirement for a FQDN. So it really > doesn't matter whether it "matches up" with anything--it's incorrectly > specified to begin with, and an RFC check should fail right there. > Now, if it were X1.ipswitch.com, that would be different story--not a > good one, I grant you, but differently argued. > > Thanks to all at Ipswitch for keeping this very techie dialogue going. > Just to put this out there again, I suggest changing the 220 to a > multiline reply and putting the X1 in the second line as the easiest, > backwards-compatible fix. I have no quibble with it being mandatory, > even. > > And I do want to say that Cisco's SMTP proxy is MUCH more broken in > this exact regard, so if anyone wants to just team up on them and > leave the Ipswitch guys alone, let's do it. ;) (The difference there > is, of course, that even though there are thousands of people using > it, they can turn it off pretty easily if it becomes a problem--not so > for us.) > > Regards, > > 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/ > 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/
