You are neglecting section 4.1.4: An SMTP server MAY verify that the domain name parameter in the EHLO command actually corresponds to the IP address of the client. However, the server MUST NOT refuse to accept a message for this reason if the verification fails: the information about verification failure is for logging and tracing only.
and also the text of section 4.1.1.1 reads: In situations in which the SMTP client system does not have a meaningful domain name (e.g., when its address is dynamically allocated and no reverse mapping record is available), the client SHOULD send an address literal (see section 4.1.3), optionally followed by information that will help to identify the client system. The keyword here is SHOULD.... which means the client does not have to or may not be able to for some reason. I have logs of thousands of "BOGUS HELOS" and have found a great many MTAs out there do not send correctly formatted HELO/EHLO... including MS Exchange. In addition I would say at least 90% of the windows MUAs out there do not send a correctly formatted HELO/EHLO. In short, I do think if you are using the value in the HELO/EHLO string to reject messages based soley on the formatting of that value, that you are in violation of RFC 2821 section 4.1.1.1 and 4.1.4 and are going to get a great many complaints from people as to "why cant I get this message from my colleage at this institution...." or "Why is my message to XX at your university rejected?" Bottom line, I have had zero false positives in my testing with bad formatted literals (bare IPs as a literal), these I reject after RCPT TO: to remain compliant and to be able to not reject abuse and postmaster messages... which by the way will also put you in violation....... Rejecting the others due to them not having a FQDN that is resolvable is just asking for more work for your mail admins.... Did you not enable the business logic with some logging first (and no rejects) to see what impact this would have on your mail server and customer base? Jim PS: results here are from my testing here with my customer base, your results may vary. On Fri, 25 Mar 2005 12:29:46 -0500, John Buysse wrote > I am with one of the universities Ben is dealing with. I was > quoting RFC 2821, not RFC 821. We are not rejecting messages with > an invalid HELO command based on RFC 1123, as we are not verifying > the the info provided. We are rejecting messages with an invalid > HELO command based on RFC 2821. If a remote server uses one of our > IP's in the HELO command, our servers will reject the message. Our > servers will also reject the message if the value given in the HELO > command is an unqualified hostname or is not an address literal, as > stated in sections > 4.1.1.1 and 4.1.3 of RFC 2821. We are only ensuring the value given > in the HELO command is syntactically correct as stated in RFC 2821. -- EsisNet.com Webmail Client _______________________________________________ Visit http://www.mimedefang.org and http://www.canit.ca MIMEDefang mailing list MIMEDefang@lists.roaringpenguin.com http://lists.roaringpenguin.com/mailman/listinfo/mimedefang