What's the benefit of SPF HELO Identity

I'm try to understand the benefit of the HELO Identity defined in RFC7208 (SPF).

There is a mail server, let's say mail.example.com. This server is used as relay for different domains.

In Section 2.4:

SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check either has not been performed or has not reached a definitive policy result by applying the check_host() function to the "MAIL FROM" identity as the <sender>.

I understand that, if the HELO has passed, there is no need to check MAIL FROM.

Similar in section 2.3:

Checking "HELO" promotes consistency of results and can reduce DNS resource usage. If a conclusive determination about the message can be made based on a check of "HELO", then the use of DNS resources to process the typically more complex "MAIL FROM" can be avoided.

Would this not lead to unchecked MAIL FROM identities?

Regards, Alex

Solution 1:

Some possible uses:

• You could reject a failing HELO identity early. Since the HELO SMTP command occurs early in the conversation, you can reject HELO identities that evaluate to fail right away. (I’m using this on my own mail host and see quite a few clients who claim to be this very mail host rejected early.)

• You could evaluate both the HELO identity and the MAIL FROM identity and use both to contribute towards some ‘score’ of legitimacy. For example, you could assign more trust to a sender whose HELO and MAIL FROM identities evaluate to pass.

• You could decide to skip evaluation of the MAIL FROM identity if you are satisfied with a HELO identity pass or fail or softfail, as a shortcut, so to speak: you don’t have to check MAIL FROM if you’re not interested in it. Note, however, that the HELO identity can easily be forged, just like the MAIL FROM identity (senders may send whatever they please), so usually you would be interested in the MAIL FROM identity (and possibly feed it into a DMARC component).

It all depends on your requirements. It also depends on what your SPF implementation allows (all of the above is supported by my own implementation, SPF Milter).

In practice, perhaps it helps to think of the HELO identity as something that is primarily useful with negative results (fail, softfail, permerror), not so much with a positive result (pass). When a mail server checks the HELO identity and encounters a negative result, it can either end the conversation right away or record the negative HELO result as the final SPF result in a header. Under such a policy, the MAIL FROM identity indeed does not need to be evaluated in these cases. Such a policy would indeed lead to the mentioned reduction of DNS resources, and so this is where I see immediate practical benefit of providing and checking the SPF HELO identity.