Re: Issues with Yahoo/AOL emails and RCVD_NUMERIC_HELO

On 29/07/18 19:21, RW wrote: On Sun, 29 Jul 2018 19:00:56 +0100 Dominic Raferd wrote: On Sun, 29 Jul 2018 at 18:33, RW wrote: On Sun, 29 Jul 2018 12:28:08 +0200 Antony Stone wrote: On Sunday 29 July 2018 at 12:17:07, Sebastian Arcus wrote yet another email that's guaranteed to fail DMA

Re: Issues with Yahoo/AOL emails and RCVD_NUMERIC_HELO

On Sun, 29 Jul 2018 12:28:08 +0200 Antony Stone wrote: On Sunday 29 July 2018 at 12:17:07, Sebastian Arcus wrote yet another email that's guaranteed to fail DMARC with a reject when posted through a mailing list, and consequently I didn't receive: > Or maybe I am misunderstanding completely

Re: Issues with Yahoo/AOL emails and RCVD_NUMERIC_HELO

On 29/07/18 19:00, Dominic Raferd wrote: On Sun, 29 Jul 2018 at 18:33, RW > wrote: On Sun, 29 Jul 2018 12:28:08 +0200 Antony Stone wrote: > On Sunday 29 July 2018 at 12:17:07, Sebastian Arcus wrote yet another > email that's guaranteed t

Re: Issues with Yahoo/AOL emails and RCVD_NUMERIC_HELO

On Sun, 29 Jul 2018 19:00:56 +0100 Dominic Raferd wrote: > On Sun, 29 Jul 2018 at 18:33, RW wrote: > > > On Sun, 29 Jul 2018 12:28:08 +0200 > > Antony Stone wrote: > > > > > On Sunday 29 July 2018 at 12:17:07, Sebastian Arcus wrote yet > > > another email that's guaranteed to fail DMARC with a

Re: Issues with Yahoo/AOL emails and RCVD_NUMERIC_HELO

On Sun, 29 Jul 2018 18:33:23 +0100 RW wrote: > On Sun, 29 Jul 2018 12:28:08 +0200 > Antony Stone wrote: > > > On Sunday 29 July 2018 at 12:17:07, Sebastian Arcus wrote yet > > another email that's guaranteed to fail DMARC with a reject when > > posted through a mailing list, and consequently I di

Re: Issues with Yahoo/AOL emails and RCVD_NUMERIC_HELO

On Sun, 29 Jul 2018 at 18:33, RW wrote: > On Sun, 29 Jul 2018 12:28:08 +0200 > Antony Stone wrote: > > > On Sunday 29 July 2018 at 12:17:07, Sebastian Arcus wrote yet another > > email that's guaranteed to fail DMARC with a reject when posted > > through a mailing list, and consequently I didn't

Re: Issues with Yahoo/AOL emails and RCVD_NUMERIC_HELO

; Mon, 23 Jul 2018 13:59:41 + (UTC) I'm not completely certain what this received header format is supposed to represent, but SA parses the first field, 82.132.242.82, as the EHLO/HELO. If that's correct then it's not RFC compliant as it's not enclosed in '[]&

Re: Issues with Yahoo/AOL emails and RCVD_NUMERIC_HELO

On 29/07/18 14:36, Matus UHLAR - fantomas wrote: On Sunday 29 July 2018 at 12:17:07, Sebastian Arcus wrote: I've been having a number of emails recently from Yahoo and AOL senders hitting the RCVD_NUMERIC_HELO rule. I'm trying to understand what is going on: 1. First off, the rule h

Re: Issues with Yahoo/AOL emails and RCVD_NUMERIC_HELO

On Sunday 29 July 2018 at 12:17:07, Sebastian Arcus wrote: I've been having a number of emails recently from Yahoo and AOL senders hitting the RCVD_NUMERIC_HELO rule. I'm trying to understand what is going on: 1. First off, the rule hits on the EHLO line - which means the it is an aut

Re: Issues with Yahoo/AOL emails and RCVD_NUMERIC_HELO

On 29/07/18 11:28, Antony Stone wrote: On Sunday 29 July 2018 at 12:17:07, Sebastian Arcus wrote: I've been having a number of emails recently from Yahoo and AOL senders hitting the RCVD_NUMERIC_HELO rule. I'm trying to understand what is going on: 1. First off, the rule hits o

Re: Issues with Yahoo/AOL emails and RCVD_NUMERIC_HELO

On Sunday 29 July 2018 at 12:17:07, Sebastian Arcus wrote: > I've been having a number of emails recently from Yahoo and AOL senders > hitting the RCVD_NUMERIC_HELO rule. I'm trying to understand what is > going on: > > 1. First off, the rule hits on the EHLO line -

Issues with Yahoo/AOL emails and RCVD_NUMERIC_HELO

I've been having a number of emails recently from Yahoo and AOL senders hitting the RCVD_NUMERIC_HELO rule. I'm trying to understand what is going on: 1. First off, the rule hits on the EHLO line - which means the it is an authenticated SMTP submission. Is the correct HELO format

Re: RCVD_NUMERIC_HELO

On Fri, 4 Mar 2016 09:08:46 +0100 Matus UHLAR - fantomas wrote: > >> On 03.03.16 16:54, RW wrote: > >> >RCVD_NUMERIC_HELO is an independent deep check and overlaps > >> >heavily with either FSL_* rule. > > >On Thu, 3 Mar 2016 17:59:33 +0100 > >

Re: RCVD_NUMERIC_HELO

defaults are still wrong defaults for others this thread started about RCVD_NUMERIC_HELO deep header scanning and it was already explained: http://mail-archives.apache.org/mod_mbox/spamassassin-users/201603.mbox/<20160302131241.67f48c6c%40gumby.homeunix.com> Maybe you could better find out

Re: RCVD_NUMERIC_HELO

Am 04.03.2016 um 09:29 schrieb Matus UHLAR - fantomas: it would at best end in the rule get such a low score that it is the same as disable it entirely - so the only correct thing to do is stop the foolish deep-header parsing why? because *then* it would no longer hit any relevant amount of h

Re: RCVD_NUMERIC_HELO

it would at best end in the rule get such a low score that it is the same as disable it entirely - so the only correct thing to do is stop the foolish deep-header parsing why? because *then* it would no longer hit any relevant amount of ham and QA corpus over time could score it higher in a safe

Re: RCVD_NUMERIC_HELO

On 03.03.16 16:54, RW wrote: >RCVD_NUMERIC_HELO is an independent deep check and overlaps heavily >with either FSL_* rule. On Thu, 3 Mar 2016 17:59:33 +0100 Matus UHLAR - fantomas wrote: I wouldn't say so, at least on my system. % zcat /var/log/mail*.gz | cat - /var/log/mail /var

Re: RCVD_NUMERIC_HELO

Am 03.03.2016 um 21:17 schrieb Axb: On 03/03/2016 09:10 PM, Reindl Harald wrote: Am 03.03.2016 um 20:59 schrieb Axb: That YOU don't like deep header parsing rule doesn't mean that they're useless. Maybe it's time that you, as a self proclamied perfectionist, fork SA and do your thing. mayb

Re: RCVD_NUMERIC_HELO

On 03/03/2016 09:10 PM, Reindl Harald wrote: Am 03.03.2016 um 20:59 schrieb Axb: On 03/03/2016 08:21 PM, Reindl Harald wrote: how do you suppose the corpus to replace ones own thinking about the *conditions* rules hit? I've no idea what the sentence means. the deep-header rules have to go

Re: RCVD_NUMERIC_HELO

Am 03.03.2016 um 20:59 schrieb Axb: On 03/03/2016 08:21 PM, Reindl Harald wrote: how do you suppose the corpus to replace ones own thinking about the *conditions* rules hit? I've no idea what the sentence means. the deep-header rules have to go away or rewritten to *not* do deep-header test

Re: RCVD_NUMERIC_HELO

On 03/03/2016 08:21 PM, Reindl Harald wrote: Am 03.03.2016 um 19:39 schrieb RW: On Thu, 3 Mar 2016 18:51:45 +0100 Reindl Harald wrote: Am 03.03.2016 um 17:54 schrieb RW: On Thu, 3 Mar 2016 15:18:36 +0100 Reindl Harald wrote: it would at best end in the rule get such a low score that it is

Re: RCVD_NUMERIC_HELO

Am 03.03.2016 um 19:39 schrieb RW: On Thu, 3 Mar 2016 18:51:45 +0100 Reindl Harald wrote: Am 03.03.2016 um 17:54 schrieb RW: On Thu, 3 Mar 2016 15:18:36 +0100 Reindl Harald wrote: it would at best end in the rule get such a low score that it is the same as disable it entirely - so the only

Re: RCVD_NUMERIC_HELO

On Thu, 3 Mar 2016 18:51:45 +0100 Reindl Harald wrote: > Am 03.03.2016 um 17:54 schrieb RW: > > On Thu, 3 Mar 2016 15:18:36 +0100 > > Reindl Harald wrote: > > > >> it would at best end in the rule get such a low score that it is > >> the same as disable it entirely - so the only correct thing to

Re: RCVD_NUMERIC_HELO

sses _2 > > it's because > > 72_active.cf:metaFSL_HELO_BARE_IP_2 __FSL_HELO_BARE_IP_2 > && !ALL_TRUSTED && !FSL_HELO_BARE_IP_1 && !__VIA_ML > && !__HAS_ERRORS_TO ^^^ I know https://bz.apache.org/SpamAssassin/show_bug.cgi?id=72

Re: RCVD_NUMERIC_HELO

:metaFSL_HELO_BARE_IP_2 __FSL_HELO_BARE_IP_2 && !ALL_TRUSTED && !FSL_HELO_BARE_IP_1 && !__VIA_ML && !__HAS_ERRORS_TO RCVD_NUMERIC_HELO is an independent deep check and overlaps heavily with either FSL_* rule. I wouldn't say so, at least on my system. % zcat /var/l

Re: RCVD_NUMERIC_HELO

Am 03.03.2016 um 17:54 schrieb RW: On Thu, 3 Mar 2016 15:18:36 +0100 Reindl Harald wrote: it would at best end in the rule get such a low score that it is the same as disable it entirely - so the only correct thing to do is stop the foolish deep-header parsing why? because *then* it would n

Re: RCVD_NUMERIC_HELO

Am 03.03.2016 um 17:54 schrieb RW: What make this all the more remarkable is that at the time you brought it up, the meta rules were wrong and most of the hits that should have gone to FSL_HELO_BARE_IP_1 were going to FSL_HELO_BARE_IP_2 instead, so you probably overestimated the spam hitting the

Re: RCVD_NUMERIC_HELO

!ALL_TRUSTED && !FSL_HELO_BARE_IP_1 && !__VIA_ML && !__HAS_ERRORS_TO ^^^ RCVD_NUMERIC_HELO is an independent deep check and overlaps heavily with either FSL_* rule. I wouldn

Re: RCVD_NUMERIC_HELO

re mutually exclusive _1 suppresses _2 RCVD_NUMERIC_HELO is an independent deep check and overlaps heavily with either FSL_* rule. score FSL_HELO_BARE_IP_12.598 1.426 3.099 2.347 score FSL_HELO_BARE_IP_21.498 1.499 1.498 1.499 score RCVD_NUMERIC_HELO 0.001 0.865 0.001 1.164 So typically

Re: RCVD_NUMERIC_HELO

even have been tried in the first place for deep-header-inspection it's an obviously bad idea as well as RCVD_NUMERIC_HELO and there is no "previous position" - i said that from the first moment on and ANYTHING doing HELO/PTR tests on any foreign received header does more harm th

Re: RCVD_NUMERIC_HELO

do more > > harm than good, and it's such an obviously bad idea that it > > shouldn't even have been tried in the first place > > for deep-header-inspection it's an obviously bad idea as well as > RCVD_NUMERIC_HELO and there is no "previous position&q

Re: RCVD_NUMERIC_HELO

y bad idea that it shouldn't even have been tried in the first place for deep-header-inspection it's an obviously bad idea as well as RCVD_NUMERIC_HELO and there is no "previous position" - i said that from the first moment on and ANYTHING doing HELO/PTR tests on any fore

Re: RCVD_NUMERIC_HELO

On Wed, 2 Mar 2016 23:25:17 +0100 Reindl Harald wrote: > Am 02.03.2016 um 23:13 schrieb RW: > > On Wed, 2 Mar 2016 22:45:15 +0100 > > Reindl Harald wrote: > > > >> Am 02.03.2016 um 22:12 schrieb RW: > >>> The only argument you have made against these rules is that they > >>> don't work for you

Re: RCVD_NUMERIC_HELO

Am 02.03.2016 um 23:13 schrieb RW: On Wed, 2 Mar 2016 22:45:15 +0100 Reindl Harald wrote: Am 02.03.2016 um 22:12 schrieb RW: The only argument you have made against these rules is that they don't work for you. They do work on the corpus that generates the rule scores, so clearly the corpus d

Re: RCVD_NUMERIC_HELO

On Wed, 2 Mar 2016 22:45:15 +0100 Reindl Harald wrote: > Am 02.03.2016 um 22:12 schrieb RW: > > The only argument you have made against these rules is that they > > don't work for you. They do work on the corpus that generates the > > rule scores, so clearly the corpus does matter > > VERY_LONG

Re: RCVD_NUMERIC_HELO

Am 02.03.2016 um 22:12 schrieb RW: The only argument you have made against these rules is that they don't work for you. They do work on the corpus that generates the rule scores, so clearly the corpus does matter VERY_LONG_REPTO_SHORT_MSG with a poison-pill score showed how much you can trus

Re: RCVD_NUMERIC_HELO

On Wed, 2 Mar 2016 15:58:10 +0100 Reindl Harald wrote: > Am 02.03.2016 um 14:12 schrieb RW: > > The FSL_HELO_BARE_IP_* rules were a bit broken until the end of > > January, but for the last month they have been proper mutually > > exclusive, deep and last-external tests. Any problems with the deep

Re: RCVD_NUMERIC_HELO

Am 02.03.2016 um 14:12 schrieb RW: The FSL_HELO_BARE_IP_* rules were a bit broken until the end of January, but for the last month they have been proper mutually exclusive, deep and last-external tests. Any problems with the deep hits are down to the rule generation corpus not matching your mai

Re: RCVD_NUMERIC_HELO

On Tue, 01 Mar 2016 23:39:58 +0100 Benny Pedersen wrote: > That one should not trigger in deap header tests RCVD_NUMERIC_HELO doesn't do what the description says. It's actually a *bare* IP address test (i.e. for an RFC violation rather than simply an IP address), something t

Re: RCVD_NUMERIC_HELO

Am 01.03.2016 um 23:39 schrieb Benny Pedersen: That one should not trigger in deap header tests see my thread about FSL_HELO_BARE_IP_2 fire on deep headers a month ago and guess how much somebody cares signature.asc Description: OpenPGP digital signature

RCVD_NUMERIC_HELO

That one should not trigger in deap header tests

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

At 02:56 15-10-2013, Stan Hoeppner wrote: In both cases the last two Received: headers in each message are forgeries as no SMTP transaction occurred. I'm sure this violates more than one SMTP RFC, but I doubt Gmane will change the way they do this any time soon. I don't think that there is any

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

ed to list mail. I only adjusted FSL_HELO_BARE_IP_2, I didn't take a look at RCVD_NUMERIC_HELO. Now that the exact nature of the problem is known, maybe the test can be modified to work with some list mail, but not this particular 'flavor'. That's a possibility. Having

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

On 10/17/2013 2:09 PM, Jonas Eckerman wrote: > I answer privately since this really isn't about SpamAssassin any more, and > SpamAssassin isn't about RFC conformance. Oh, but it does directly relate to the above two rules. And I believe this is a healthy discussion. It will educate others as to

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

On 10/16/2013 3:01 AM, Jonas Eckerman wrote: >> Operators of newsgroups which mirror/archive mailing >> lists, and allow posting from a web interface, are adding forged >> Received: headers before sending an email to the respective list >> server. > > In what way are they forged? I'm to this list

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

>Operators of newsgroups which mirror/archive mailing >lists, and allow posting from a web interface, are adding forged >Received: headers before sending an email to the respective list >server. In what way are they forged? Do they contain addresses that doesn't match the system adding the receiv

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

tails: (4.8 points, 4.2 required) >>>> pts rule name description >>>> >>>> ----- >>>> 2.8 FSL_HELO_BARE_IP_2 FSL_HELO_BARE_IP_2 >>>> 1.2 RCVD_NU

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

- 2.8 FSL_HELO_BARE_IP_2 FSL_HELO_BARE_IP_2 1.2 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5314] The others have

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

t list mail, > and none of the spam hits are, so it would seem reasonable to add an > exclusion for list messages. I did some digging and have discovered precisely why FSL_HELO_BARE_IP_2, RCVD_NUMERIC_HELO, et al falsely hit on much list mail. It's quite interesting. Operators of newsgroup

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

description >> - >> 2.8 FSL_HELO_BARE_IP_2 FSL_HELO_BARE_IP_2 >> 1.2 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO >> 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% >> [sco

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

eqa.spamassassin.org/?daterev=20131014-r1531815-n&rule=FSL_HELO_BARE_IP_2+RCVD_NUMERIC_HELO&srcpath=&g=Change> are quite similar: MSECS SPAM% HAM%S/O RANKSCORE NAME 0 60.7267 0.3533 0.994 0.852.00FSL_HELO_BARE_IP_2 <http://ruleqa.spamassass

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

_HELO_BARE_IP_2 FSL_HELO_BARE_IP_2 > 1.2 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO > 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% > [score: 0.5314] The others have addressed the "two rules" you mentioned

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

On 10/13/2013 11:07 AM, John Hardin wrote: ... > Yes. It will take a day or two to make it through masscheck. And we've > had corpora starvation issues the last few weeks; if the ham corpus gets > thin again updates may be delayed. FSL_HELO_BARE_IP_2 3am CDT w/score 2.8 11am CDT w/score 2.4 Upd

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

On 10/13/2013 2:17 PM, John Hardin wrote: On Sun, 13 Oct 2013, Kevin A. McGrail wrote: On 10/13/2013 12:33 PM, John Hardin wrote: On Sun, 13 Oct 2013, John Hardin wrote: > And we've had corpora starvation issues the last few weeks; if the ham > corpus gets thin again updates may be delaye

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

On Sun, 13 Oct 2013, Kevin A. McGrail wrote: On 10/13/2013 12:33 PM, John Hardin wrote: On Sun, 13 Oct 2013, John Hardin wrote: > And we've had corpora starvation issues the last few weeks; if the ham > corpus gets thin again updates may be delayed. Yeah, we're starved for ham again; I

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

On 10/13/2013 12:33 PM, John Hardin wrote: On Sun, 13 Oct 2013, John Hardin wrote: And we've had corpora starvation issues the last few weeks; if the ham corpus gets thin again updates may be delayed. Yeah, we're starved for ham again; I don't know how quickly this change will go out, sorry.

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

On Sun, 13 Oct 2013, John Hardin wrote: And we've had corpora starvation issues the last few weeks; if the ham corpus gets thin again updates may be delayed. Yeah, we're starved for ham again; I don't know how quickly this change will go out, sorry. -- John Hardin KA7OHZ

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

On Sun, 13 Oct 2013, Stan Hoeppner wrote: On 10/12/2013 9:28 PM, John Hardin wrote: On Sat, 12 Oct 2013, Stan Hoeppner wrote: Steve, the one who wrote this regex, would you please explain your reasoning behind giving this rule a score so high as 2.8, That score was auto-assigned by masschec

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

On 10/12/2013 9:28 PM, John Hardin wrote: > On Sat, 12 Oct 2013, Stan Hoeppner wrote: > >> Steve, the one who wrote this regex, would you please explain your >> reasoning behind giving this rule a score so high as 2.8, > > That score was auto-assigned by masscheck, where it is doing quite well: >

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

On Sat, 12 Oct 2013, Stan Hoeppner wrote: Steve, the one who wrote this regex, would you please explain your reasoning behind giving this rule a score so high as 2.8, That score was auto-assigned by masscheck, where it is doing quite well: http://ruleqa.spamassassin.org/?rule=FSL_HELO_BARE_IP

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

On Sat, 12 Oct 2013, Stan Hoeppner wrote: Content analysis details: (4.8 points, 4.2 required) Why did you lower the required score? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

On 10/12/2013 1:04 PM, Benny Pedersen wrote: > Stan Hoeppner skrev den 2013-10-12 18:26: > >> FSL_HELO_BARE_IP_2 needs to have a -much- lower score, or be eliminated >> entirely, as it overlaps with at least 3 other tests, as pointed out >> previously by another user. If a message makes it throug

Re: FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

_IP_2 1.2 RCVD_NUMERIC_HELO Received: contains an IP address used for HELO 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.5314] yep a overlap, but still under 5.0 in score ? for the overlap create a bug might help more

FSL_HELO_BARE_IP_2 & RCVD_NUMERIC_HELO

usly wrong. Example: Content analysis details: (4.8 points, 4.2 required) pts rule name description -- -- 2.8 FSL_HELO_BARE_IP_2 FSL_HELO_BARE_IP_2 1.2 RCVD_NUMERIC_HELO Received: contains an IP addres

Re: Is RCVD_NUMERIC_HELO meant to match helo=2xx.2.2xx.62.fix.example.com ?

Mark Martinec wrote: > Per Jessen, >> Per Jessen wrote: >> > I was just wondering - >> > >> > RCVD_NUMERIC_HELO will match "helo=2xx4.2.2xx.62.fix.example.com" - >> > but is that intentional? It's not exactly a numeric helo? &g

Re: Is RCVD_NUMERIC_HELO meant to match helo=2xx.2.2xx.62.fix.example.com ?

Per Jessen, > Per Jessen wrote: > > I was just wondering - > > > > RCVD_NUMERIC_HELO will match "helo=2xx4.2.2xx.62.fix.example.com" - > > but is that intentional? It's not exactly a numeric helo? > > That should have read "helo=2xx.2.2xx.62.

Re: Is RCVD_NUMERIC_HELO meant to match helo=2xx.2.2xx.62.fix.example.com ?

Per Jessen wrote: > I was just wondering - > > RCVD_NUMERIC_HELO will match "helo=2xx4.2.2xx.62.fix.example.com" - > but is that intentional? It's not exactly a numeric helo? That should have read "helo=2xx.2.2xx.62.fix.example.com". /Per Jessen, Zürich

Is RCVD_NUMERIC_HELO meant to match helo=2xx.2.2xx.62.fix.example.com ?

I was just wondering - RCVD_NUMERIC_HELO will match "helo=2xx4.2.2xx.62.fix.example.com" - but is that intentional? It's not exactly a numeric helo? /Per Jessen, Zürich