Fh_helo_ends_dot

[fiftyMIPsparc]

It seems that a lot of my mail (especially short messages) is getting marked as spam. I should first say that I'm not on any blacklists and my volume is very low, and I have SPF and DomainKeys configured.

I just sent a few test messages to another email account so I could take a look at the headers as they are received by others. I noticed the following in the X-Spam-Status header:

FH_HELO_ENDS_DOT=3.02

It appears that my spam score is being raised because my HELO ends in a dot. I was under the assumption that HELO should contain your FQDN-- which, by definition, ends in a dot. This makes short messages VERY likely to be blocked by spam filters, including my own.

There's nothing on the SpamAssassin wiki about this (that just happens to be the only rule that doesn't have a page created for it), and I've noticed a few other cPanel/WHM servers are doing this as well. I tried specifying a HELO name in /etc/heloname and switching on the relevant option in Exim, but the issue persists.

[tpawlowski]

Hello,

I am experiencing the same issue as the above poster. Email being sent from the server gets marked as spam by the recipient server due to the following SpamAssassin criteria:

X-Spam-Status: Yes, hits=5.903 tagged_above=1 required=5
tests=FH_HELO_ENDS_DOT=3.02, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.672,
SPF_NEUTRAL=1.21
X-Spam-Level: *****

The problem is that the sending server does not report a hostname that ends in a dot:

tom@chthonic:~$ telnet somesite.com 25
Trying 65.98.14.NNN...
Connected to somesite.com.
Escape character is '^]'.
220-somesite.com ESMTP Exim 4.69 #1 Thu, 10 Sep 2009 17:18:47 -0400
220-We do not authorize the use of this system to transport unsolicited,
220 and/or bulk e-mail.
HELO
250 somesite.com Hello [65.98.0.NNN]

Has anyone else run into this problem and found any solutions for it? Thanks in advance!

Regards,
--T

[bapline]

Need an answer to this as well.

[cpanelchrish]

neat. I found the problematic rule, and haven't a clue the logic behind it. Way way way overly agressively scored.

Indeed the dot is perfectly valid; this is the so-called "root label", which under every (well, every correct) school of thought is representative of an FQDN. This was a huge fight at my last gig (developing mail filtering software), mailing lists were lit up again, the end result was basically - an FQDN, strictly speaking, is an absolute domain name; an absolute domain name, per section 3.1 RFC 1034, terminates with a root label (dot).

When a user needs to type a domain name, the length of each label is
omitted and the labels are separated by dots ("."). Since a complete
domain name ends with the root label, this leads to a printed form which
ends in a dot. We use this property to distinguish between:

- a character string which represents a complete domain name
(often called "absolute"). For example, "poneria.ISI.EDU."

- a character string that represents the starting labels of a
domain name which is incomplete, and should be completed by
local software using knowledge of the local domain (often
called "relative"). For example, "poneria" used in the
ISI.EDU domain.

Anyway...we came to the conclusion the most adaptable implementation was to consider "host.domain.tld", "host.domain.tld." and "domain.tld." to be an FQDN, and although "domain.tld" isn't an FQDN, treat it as such for interoperability.

The problematic rule looks like so:

X-Spam-Relays-Untrusted =~ /^[^\]]+ helo=[^ ]+\. by=/

So indeed the regex works as designed, but the scoring is way, way, way overly aggressive:

50_scores.cf:score FH_HELO_ENDS_DOT 3.599 3.020 1.395 2.308

Basing 70% of your determination of spam on something as widely disputed as whether an FQDN should terminate with a dot? No. Methinks scoring 0.5 would be more appropriate, if you decide to score it at all (personally I think the rule should be nuked).

BIG DISCLAIMER: everything below here is unsupported (I think). Modifying spamassassin scoring, and/or creating your own rules is a pandora's box of potentially endless support queries - if you know what you're doing, take all of the below as "theoretical".

Not sure the cPanel-friendly way to do this, but what I'd normally do is something like this in a custom spamassassin rule:

meta MT_DOTHELO_ADJUST FH_HELO_ENDS_DOT
score MT_DOTHELO_ADJUST -3.0
describe MT_DOTHELO_ADJUST meta scoring adjustment for aggressive HELO rule

adding custom rules is unsupported, etc etc etc - BUT, if you did this, probably the most sane method for applying it globally is creating an include file, and putting the rule in there.

I write heaps of my own rules, and include them as such:

gentoob0x spamassassin # grep include /etc/mail/spamassassin/local.cf
include /etc/mail/spamassassin/custom/20_header.cf
include /etc/mail/spamassassin/custom/20_body.cf

Obviously /etc/mail/spamassassin/custom is a directory I created, and "20_header.cf" as well "20_body.cf" are rules files I've created. If I wanted to separate out META into their own, I might add a line to local.cf like:

include /etc/mail/spamassassin/custom/99_meta.cf

and within the aforementioned file put the META (which ends up being a meta scoring adjustment. )


As to the formally recommended way of doing this? Not sure what the tag line is for that, normally this sort of thing ends up popping up on SA's radar over time, and they adjust rules accordingly. If that's the route here, quite literally no interaction required - it will get sorted automagically.

[tpawlowski]

Thanks a bunch for looking into this, Chris I've submitted a bug to SpamAssassin concerning this issue. Folks can follow it here:

https://issues.apache.org/SpamAssass...ug.cgi?id=6196

Regards,
Tom Pawlowski

[cpanelchrish]

interesting. Only skimming the bug, but I do see the message header now - "localhost." is odd enough, and invalid, but why would you score so highly on a HELO that's so many hops back? Rather, that's the net result of checking this header.

If parsing that deeply in the header, something like a HELO ending in a dot is certainly not suitable for determining 70% of your overall spam score.

I very, very rarely, see a legitimate spam message go through that many hops. In 2002 maybe, you'd see spam that passed through heaps of relays that weren't compromised. Nowadays no, pretty much the entirety of it comes either from an infected host on residential broadband, or a smaller (but significant) proportion from a compromised server - in any case the message will be sent via direct connection to the recipient MX. Obviously I can't make this as a blanket statement, but this many hops alone is a somewhat reasonable indicator of ham - at the very least, no matter how broken the HELO, if it's this many layers deep, a very poor spam indicator. The behaviour of the connecting host is generally an amazing indicator of ham vs spam.

If they want to score this I'd say start the base before training off considerably lower. If their corpus still contains a surprisingly high proportion of spam messages with this trait, we as a community need to help out and contribute by submitting false triggers. The are, after all, not charging us

The other thing to look at, is preventing the addition of this X header on whichever of your MTA's is adding it. It's not needed if it's going through this many other hops.