SA 3.0.2 currently performs a handful of tests against HELO greetings that contain an IP address. These tests don't currently fire when an "address literal" is used in the HELO greeting, but they should.
See section 3.6 of RFC 2821: | - The domain name given in the EHLO command MUST BE either a primary | host name (a domain name that resolves to an A RR) or, if the host | has no name, an address literal as described in section 4.1.1.1. and section 4.1.3: 4.1.3 Address Literals | Sometimes a host is not known to the domain name system and | communication (and, in particular, communication to report and repair | the error) is blocked. To bypass this barrier a special literal form | of the address is allowed as an alternative to a domain name. For | IPv4 addresses, this form uses four small decimal integers separated | by dots and enclosed by brackets such as [123.255.37.2], which | indicates an (IPv4) Internet Address in sequence-of-octets form. For | IPv6 and other forms of addressing that might eventually be | standardized, the form consists of a standardized "tag" that | identifies the address syntax, a colon, and the address itself, in a | format specified as part of the IPv6 standards [17]. Technically, addresses that are NOT enclosed in brackets are illegal, but those are the only ones that SA sniffs out currently. Extending the current rules to include literals can probably be done by simply changing the sniff code to look for open and close brackets, but I haven't looked so I'm just guessing. As far as that goes, the tests might already do this, and just not firing. I think the four affected rules are RCVD_HELO_IP_MISMATCH, RCVD_NUMERIC_HELO, RCVD_ILLEGAL_IP, RCVD_BY_IP -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
