{"id":28,"date":"2020-08-23T14:19:04","date_gmt":"2020-08-23T19:19:04","guid":{"rendered":"https:\/\/sourceopen.com\/?p=28"},"modified":"2020-08-24T19:01:02","modified_gmt":"2020-08-25T00:01:02","slug":"fix-t_spf_helo_permerror-in-spamassassin","status":"publish","type":"post","link":"https:\/\/sourceopen.com\/index.php\/fix-t_spf_helo_permerror-in-spamassassin\/","title":{"rendered":"Fix T_SPF_HELO_PERMERROR in Spamassassin"},"content":{"rendered":"\n

So I thought I had my spf (Sender Policy Framework<\/a>) records setup correctly. They all passed the various <\/a>test sites<\/a>. <\/p>\n\n\n\n

Nevertheless I kept seeing this one error in my spamassassin produced headers:<\/p>\n\n\n\n

T_SPF_HELO_PERMERROR<\/code><\/pre>\n\n\n\n
I was unable to find a lot of info on this specific error. Everyone seemed to keep saying you needed spf records for your domain, blah, blah…<\/p>\n\n\n\n
The nice thing is that this does seem to be a zero-weighted rule by default, but who’s to say some admins haven’t added negative weight to this, maybe even some big mail sites like GMail.<\/p>\n\n\n\n
The key to finally figuring out the solution to this error (I mean who likes to see “PERMERROR!!!???!!!” That’s quite a permanent Error by the sound of it) was in the name itself– “HELO”  When a mail admin sees hello spelled like that he or she has to think of the SMTP conversation where the mail servers starts out with a HELO greeting. (https:\/\/tools.ietf.org\/html\/rfc5321<\/a>) Indeed when a mail server says HELO (or perhaps EHLO (sic.) for modern servers) it gives its host name. <\/p>\n\n\n\n
I was able to get rid of this error message by setting up an spf record for my mail server’s hostname itself, not just for my domain.<\/p>\n\n\n\n
For example, you may already have your domain spf record setup to something like this:<\/p>\n\n\n\n
example.com  TXT \"v=spf1 mx ip4:111.222.333.444 ip4:222.333.444.555 a:mail.example.com a:bkpmail.example.com -all\"<\/code><\/pre>\n\n\n\n
This works great for your domain. You only send mail out of those two mail servers identified both by name and by ip. However you will still get the dreaded T_SPF_HELO_PERMERROR header from Spamassassin. <\/p>\n\n\n\n
To solve this I also added an spf record for the mail server itself:<\/p>\n\n\n\n
mail.example.com  TXT \"v=spf1 mx ip4:111.222.333.444 ip4:222.333.444.555 a:mail.example.com a:bkpmail.example.com -all\"<\/code><\/pre>\n\n\n\n
Note the first example is an spf TXT record for just the domain name, “example.com”. (The start of the line)<\/p>\n\n\n\n
Whereas the second example is an spf TXT record for “mail.example.com”. (You would want one for the backup mail server too.)<\/p>\n\n\n\n
Now there is no longer a T_SPF_HELO_PERMERROR from Spamassassin because there is no longer a permanent error on the HELO server name. Now I get the prized SPF_HELO_PASS header instead!<\/p>\n\n\n\n
Will this help you at all<\/em>? I have no idea. Like I said above the rule defaults to a zero weighting, but people change these weights all the time, and future version of SA may change them too. This was all tested with SA 3.4.2 .<\/p>\n","protected":false},"excerpt":{"rendered":"
So I thought I had my spf (Sender Policy Framework) records setup correctly. They all passed the various test sites. Nevertheless I kept seeing this one error in my spamassassin produced headers: I was unable to find a lot of … Continue reading →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[3,4,23,28,29,2,27,20,25,26,30,24],"_links":{"self":[{"href":"https:\/\/sourceopen.com\/index.php\/wp-json\/wp\/v2\/posts\/28"}],"collection":[{"href":"https:\/\/sourceopen.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sourceopen.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sourceopen.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sourceopen.com\/index.php\/wp-json\/wp\/v2\/comments?post=28"}],"version-history":[{"count":1,"href":"https:\/\/sourceopen.com\/index.php\/wp-json\/wp\/v2\/posts\/28\/revisions"}],"predecessor-version":[{"id":29,"href":"https:\/\/sourceopen.com\/index.php\/wp-json\/wp\/v2\/posts\/28\/revisions\/29"}],"wp:attachment":[{"href":"https:\/\/sourceopen.com\/index.php\/wp-json\/wp\/v2\/media?parent=28"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sourceopen.com\/index.php\/wp-json\/wp\/v2\/categories?post=28"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sourceopen.com\/index.php\/wp-json\/wp\/v2\/tags?post=28"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}