Wizard IT Products

hello,

i'm thinking about magicspam protection policy 'HELO MUST RESOLVE'.
when i am reading http://en.wikipedia.org/wiki/Anti-spam_ ... O_checking, i think, i must not enable this protection policy, actually:

RFC 5321 section 4.1.4 says that "An SMTP server MAY verify that the domain name argument in the EHLO command actually corresponds to the IP address of the client. However, if the verification fails, the server MUST NOT refuse to accept a message on that basis.", so to be in compliance with the RFCs, rejecting connections must be based on additional information/policies.

but some lines below in this wiki article:

Refusing to accept email whose HELO/EHLO argument does not resolve in DNS. Unfortunately, some email system administrators ignore section 2.3.5 of RFC 5321 and administer the MTA to use a nonresolvable argument to the HELO/EHLO command.

so i am not sure, how to go on...
what's your opinion?

That is a very interesting question Andi and we are glad you raised it!

You will probably note that this particular rule is *not* on by default - and that is specifically because of the rather.. loose.. RFC specifications related to this.

Now, this said, the rule does exist due to the clauses raised by MAAWG (Messaging Anti-Abuse Work Group) in their 'Sender Best Communications Practices' publication:

-- snip --
In addition to a matching and consistent reverse and forward DNS to help identify IPs, the
HELO/EHLO and MAIL-FROM should remain consistent for a campaign (also for
subsequent campaigns of the same nature) and be presented in the form of a domain name
rather than an IP address. Changing names and/or identifiers midstream during a campaign
can present significant delivery problems.
The HELO/EHLO should be configured to match the reverse lookup of the mailing IP so
that the domain remains the same across the various parts of the header and connection
mechanism. If multiple servers are used to deliver mail through the same externally visible
IP, their HELO/EHLO should be within the same domain and not identify themselves as
different domains to remain consistent.
-- end snip --

Now, the particular rule in question does not go to the depths suggested as 'best practice' by the above statements, but it is an abstraction of the philosophy behind it whereby an issued HELO should at the least resolve.

As to the RFC in question - that is correct. The RFC does indeed state that a server *must not* refuse. However, when we take into account that the RFC in question was drafted well over 10 years ago, and has since been circumvented, mutated, and challenged on several levels by a great many pieces of technology since with no response refutation or comment, we believe that this policy should be an option that is given to the end operator to choose to enforce or not dependent on the policies of their specific operation - particularly when one considers that section 4.1.1.1 of the very same RFC states that a HELO *must* follow the specifications of a proper domain as specified in RFC821 and 1035 as an expression of a resolvable RR - quite the double standard.

Now this said, we have it *off* by default for more reasons than just RFC compliance. In general we try to avoid DNS checks except when required as there is overhead and 3rd party reliance involved for such lookups. Additionally, there are indeed several server operators out there that do not follow standards let alone best practices, and as such there are possibilities of false positives with such a check in place.

We would of course welcome hearing any other views on this.