6

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

Alex
  • 63
  • 4
  • 2
    Interesting question. Indeed, why is the HELO check considered useful in the first place, and why was it upgraded from an optional extra check in the earlier SPF spec to conditionally replacing the actually relevant check in the current spec? Without knowing the reasoning it just seems like it creates a big hole where there wasn't one before. – Håkan Lindqvist May 04 '21 at 13:14
  • 2
    ‘I understand that, if the HELO has passed, there is no need to check MAIL FROM.’ This is not what the RFC says. It depends on your policy. If your policy is that a HELO `pass` is sufficient, then indeed you don’t need to check MAIL FROM. But usually that is not a good policy. – glts May 04 '21 at 14:46

2 Answers2

4

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).

  • Also, while not directly an answer to your question, remember that the HELO identity is also evaluated in place of the MAIL FROM identity when your mail server sends bounce messages, that is messages with an empty envelope sender (<>). So setting it up properly is anyway somewhat of a requirement.

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.

glts
  • 897
  • 5
  • 17
  • 1
    Sure. that are all possibilities I can do with that. The RFC should not state that HELO pass is enough to skip MAIL FROM. The SPF record of HELO could be complete different domain. So I see no benefit to check this identity. The check of MAIL FROM would be sufficient. To set the SPF record for the FQDN of the HELO string just give no added value. – Alex May 05 '21 at 09:45
0

HELO checks are only sufficient "If a conclusive determination" can be made according to your own quote from the RFC. -- This is not the case unless you trust the domain, the connection and DNS.

It is a riddle to me why the RFC is written like that.

Nevertheless will I make sure my servers send legit HELO identities. Reason: mail servers start rejecting mails from my domain (unfounded spam suspicion), but still accept legit mails which my servers only forward correctly to a specific account. (On those mails MAIL FROM SPF will always fail.)

Maybe most mail subsystems do not do it yet: but if they evaluate (my) servers across the boundaries of a single mail (now or in the future), I want them to trust my domains/servers. If they accept my forwards and start trusting mail originating here or if they keep trusting my forwards because mail originating here shines on all SPF checks, then I'm all in on SPF.

And on the receiving end:

Strictly refusing service on negative HELO identity checks equals refusing service to SPF-unaware clients. Reacting on positive HELO checks equals not reacting at all, i.e. continuing with the session.

So in conclusion: maybe the HELO SPF identity can serve in your mail system as one tiny piece in spam control etc. If it does, great. On my systems it doesn't.

Robert Siemer
  • 542
  • 9
  • 19
  • ‘refusing service on negative HELO identity checks equals refusing service to SPF-unaware clients’ – this is not the case. Clients that do not participate in SPF evaluate to `none`. A `none` result is neither positive nor negative, no action is taken by the receiving party. – glts Dec 29 '21 at 09:04