Mailing List Archive

check_rbl digging too deep
We had an inbound message get rejected because it was sent from a cell
phone, shouldn't SA be checking the most recent hop? Is there a way to
make this the default?

I have this in local.cf:
header    RCVD_IN_rbl2spamhausz   eval:check_rbl('spamhausz',
'zen.spamhaus.org.')
score     RCVD_IN_rbl2spamhausz   3.5

2019-06-23 10:18:19 1hf4G0-0002xm-Vu H=st43p00im-zteg10073401.me.com
[17.58.63.181]:53270 I=[1.1.1.1]:25
X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no
F=<jtsomedudesr@icloud.com> rejected after DATA: Call Katy Computer $
Envelope-from: <jtsomedudesr@icloud.com>
Envelope-to: <kevin.somedude@somedomain.com>
P Received: from st43p00im-zteg10073401.me.com ([17.58.63.181]:53270)
        by mx6.filter1.com with esmtps
(TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
        (Exim 4.91)
        (envelope-from <jtsomedudesr@icloud.com>)
        id 1hf4G0-0002xm-Vu
        for kevin.somedude@somedomain.com; Sun, 23 Jun 2019 10:18:17 -0500
  DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com;
        s=04042017; t=1561303096;
        bh=r2TrvoaceRP0b+VFuQY+IGTZNdeyIP+gpz7yR0zojuM=;
h=Content-Type:From:Mime-Version:Date:Subject:Message-Id:To;
b=zvUTXxLFQN3PkKNuMqWkXrN5nmfErusd+BJLae3e5oWTBwHhLPo49ojGUOtMZKsrN
dCj6bSPMuRW2TNPvSvqrP+ONFxDAkR73efrESuX6FkDDRDisDxJrG1RX5EEtogrDGu
0JePNiPvpQbNHia1El2B1IF1sREdBrdywIUBcJbOYWdxBHccCJVeuV56RaFjk1D2Xw
kg9ebd39jn0lXnifQDhoK0bfiW6IQ3VisLxrcDHby9xforIWwSrX+/T2UOlI5TN2Bb
mUFsu/TylzkmK4Ngdb1Pyu16F7wt0y8PBaKfOJpZDuW+b4CYZg/VbSlVGuRI7qJGLM
         2UhwHomJLGxZA==
P Received: from [10.87.198.48] (mobile-166-172-61-102.mycingular.net
[166.172.61.102])
        by st43p00im-zteg10073401.me.com (Postfix) with ESMTPSA id
34C735E01E0
        for <kevin.somedude@somedomain.com>; Sun, 23 Jun 2019 15:18:16
+0000 (UTC)
  Content-Type: text/plain; charset=utf-8
  Content-Transfer-Encoding: quoted-printable
F From: JOHN somedude <jtsomedudesr@icloud.com>
  Mime-Version: 1.0 (1.0)
  Date: Sun, 23 Jun 2019 11:18:14 -0400
  Subject: Very nice
I Message-Id: <8D5BEF14-0283-47DE-A819-60D2797CC6BE@icloud.com>
T To: kevin.somedude@somedomain.com
  X-Mailer: iPad Mail (16F203)
  X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,,
definitions=2019-06-23_12:,,
 signatures=0
  X-Proofpoint-Spam-Details: rule=notspam policy=default score=0
suspectscore=1 malwarescore=0
 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 mlxscore=0
 mlxlogscore=284 adultscore=0 classifier=spam adjust=0 reason=mlx
 scancount=1 engine=8.0.1-1812120000 definitions=main-1906230132
  X-Spam-Score: 9.8

 Content analysis details:   (9.8 points, 8.5 required)

  pts rule name              description
 ---- ----------------------
--------------------------------------------------
  0.2 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was
                             blocked.  See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                              for more information.
                             [URIs: icloud.com]
  3.5 RCVD_IN_rbl2spamhausz  RBL: No description available.
                             [166.172.61.102 listed in zen.spamhaus.org]
  0.8 RCVD_IN_rbl2dnsbl_2    RBL: No description available.
                             [166.172.61.102 listed in
dnsbl2.uceprotect.net]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
                             low trust
                             [17.58.63.181 listed in list.dnswl.org]
  1.2 RCVD_IN_UCEPROTECT2    RBL: Network listed in
                             dnsbl-2.uceprotect.net
                             [NET 17.58.63.0/24 is UCEPROTECT-Level2
listed]
                             [because 5 abusers are hosted by]
                             [APPLE-ENGINEERING - Apple Inc., US/AS714
there.]
               [See:
<http://www.uceprotect.net/rblcheck.php?ipr=17.58.63.181>]
  1.2 RCVD_IN_UCEPROTECT1    RBL: Listed in dnsbl-1.uceprotect.net
                             [IP 17.58.63.181 is UCEPROTECT-Level 1
listed.]
                [See
<http://www.uceprotect.net/rblcheck.php?ipr=17.58.63.181>]
  1.0 RCVD_IN_rbl2unsubscore RBL: No description available.
                             [17.58.63.181 listed in ubl.unsubscore.com]
  0.9 RCVD_IN_BS_SPAM        RBL: BACKSCATTERER: sender is a spam source
                             [17.58.63.181 listed in ips.backscatterer.org]
 -1.2 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (jtsomedudesr[at]icloud.com)
 -0.1 SPF_PASS               SPF: sender matches SPF record
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.8 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not
necessarily
                             valid
 -0.8 DKIM_VALID             Message has at least one valid DKIM or DK
signature
 -0.1 DKIM_VALID_EF          Message has a valid DKIM or DK signature from
                             envelope-from domain

--
John Schmerold
Katy Computer Systems, Inc
https://katycomputer.com
St Louis
Re: check_rbl digging too deep [ In reply to ]
On 24 Jun 2019, at 18:15, John Schmerold wrote:

> We had an inbound message get rejected because it was sent from a cell
> phone, shouldn't SA be checking the most recent hop?

Only if that's what *you* want it to do...

Sometimes you want it to look at the whole transit path, sometimes not.
Many DNSBLs list addresses of Just Plain Bad devices and networks

> Is there a way to make this the default?

Yes, but that would be bad, so we don't. We do have a way to documented
way to switch it on for specific DNSBL rules. See the documentation of
the "-lastexternal" suffix for DNSBL rules in 'perldoc
Mail::SpamAssassin::Conf' fort the details.

See also the many rules involving the Spamhaus Zen list in the default
rules file 20_dnsbl_tests.cf. They do reasonable things. You may want to
toss out your local Zen-based rule(s) and just use what's in the
distribution.

It is important to understand that Zen is a multiplexed DNSBL, with
listings of very different classes of IPs you don't want sending you
mail, some (PBL) only suspect at the last hop others (SBL, DROP) worthy
of shunning at any point in the path.


> I have this in local.cf:
> header    RCVD_IN_rbl2spamhausz   eval:check_rbl('spamhausz',
> 'zen.spamhaus.org.')
> score     RCVD_IN_rbl2spamhausz   3.5

That's more than a bit reckless. You're free to do it with your mail
system, of course, but I definitely wouldn't...
I also wouldn't use any of the "UCEPROTECT" lists

>  Content analysis details:   (9.8 points, 8.5 required)

I guess that 8.5 kinda accommodates the effects of using
hyper-aggressive DNSBLs and a manually-overscored deep-inspecting rule
for anything listed in any slice of Zen.


>   pts rule name              description
>  ---- ----------------------
> --------------------------------------------------
>   0.2 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query
> to URIBL was
>                              blocked. 
> See
> http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
>                               for more
> information.
>                              [URIs:
> icloud.com]

If you can't query URIBL in a legitimate way, don't do it at all. It
does you no good but it is penalizing every message containing any URI
for you.



--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Re: check_rbl digging too deep [ In reply to ]
Hi

On 25/06/19 00:15, John Schmerold wrote:
> We had an inbound message get rejected because it was sent from a cell
> phone, shouldn't SA be checking the most recent hop? Is there a way to
> make this the default?
>
> I have this in local.cf:
> header    RCVD_IN_rbl2spamhausz   eval:check_rbl('spamhausz',
> 'zen.spamhaus.org.')
> score     RCVD_IN_rbl2spamhausz   3.5
>
Please do *not* use ZEN in all the received chain without checking
return codes
(https://docs.spamhaustech.com/10-data-type-documentation/datasets/040-zones.html)

ZEN includes PBL, that is a list mantained by ISP all over the world,
and it is perfectly legit to find the first public IP in the received
chain to be listed in PBL. You should only reject mail from ZEN if you
use the -lastexternal flag

--
Best regards,
Riccardo Alfieri

Spamhaus Technologies
https://www.spamhaustech.com/
Re: check_rbl digging too deep [ In reply to ]
On 24.06.19 17:15, John Schmerold wrote:
>We had an inbound message get rejected because it was sent from a cell
>phone, shouldn't SA be checking the most recent hop? Is there a way to
>make this the default?
>
>I have this in local.cf:
>header??? RCVD_IN_rbl2spamhausz?? eval:check_rbl('spamhausz',
>'zen.spamhaus.org.')
>score???? RCVD_IN_rbl2spamhausz?? 3.5

You have explicitly configured SA to check deeply by using this rule, which
caused the hits.

These are the default rules that do not check deeply:

header __RCVD_IN_ZEN eval:check_rbl('zen', 'zen.spamhaus.org.')
header RCVD_IN_XBL eval:check_rbl('zen-lastexternal', 'zen.spamhaus.org.', '^127\.0\.0\.[45678]$')
header RCVD_IN_PBL eval:check_rbl('zen-lastexternal', 'zen.spamhaus.org.', '^127\.0\.0\.1[01]$')

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Silvester Stallone: Father of the RISC concept.
Re: check_rbl digging too deep [ In reply to ]
Hi,

On 25/06/19 11:00, Matus UHLAR - fantomas wrote:

>
> header RCVD_IN_XBL????????????? eval:check_rbl('zen-lastexternal',
> 'zen.spamhaus.org.', '^127\.0\.0\.[45678]$')
>
I take this opportunity to point out that the correct rule for XBL
should be:

header RCVD_IN_XBL eval:check_rbl('zen-lastexternal',
'zen.spamhaus.org.', '^127\.0\.0\.[4567]$')

The return code 127.0.0.8 has been dropped a long time ago.

More infos on
https://docs.spamhaustech.com/10-data-type-documentation/datasets/030-datasets.html#xbl

--
Best regards,
Riccardo Alfieri

Spamhaus Technology
https://www.spamhaustech.com/
Re: check_rbl digging too deep [ In reply to ]
On Tue, Jun 25, 2019 at 11:34:33AM +0000, Riccardo Alfieri wrote:
> I take this opportunity to point out that the correct rule for XBL should
> be:
>
> header RCVD_IN_XBL eval:check_rbl('zen-lastexternal', 'zen.spamhaus.org.',
> '^127\.0\.0\.[4567]$')
>
> The return code 127.0.0.8 has been dropped a long time ago.
>
> More infos on https://docs.spamhaustech.com/10-data-type-documentation/datasets/030-datasets.html#xbl

Thanks for the info, I've removed .8 from RCVD_IN_XBL rule.

Cheers,
Henrik
Re: check_rbl digging too deep [ In reply to ]
Henrik K skrev den 2019-06-25 14:16:
> On Tue, Jun 25, 2019 at 11:34:33AM +0000, Riccardo Alfieri wrote:
>> I take this opportunity to point out that the correct rule for XBL
>> should
>> be:
>>
>> header RCVD_IN_XBL eval:check_rbl('zen-lastexternal',
>> 'zen.spamhaus.org.',
>> '^127\.0\.0\.[4567]$')
>>
>> The return code 127.0.0.8 has been dropped a long time ago.
>>
>> More infos on
>> https://docs.spamhaustech.com/10-data-type-documentation/datasets/030-datasets.html#xbl
>
> Thanks for the info, I've removed .8 from RCVD_IN_XBL rule.

https://docs.spamhaustech.com/10-data-type-documentation/datasets/040-zones.html

add 9 to sbl test ?

possible aswell new test for authbl ?
Re: check_rbl digging too deep [ In reply to ]
Sorry guys, I don't know what happened, my client sent a lot of emails
during drafting :(

Apologies

--
Best regards,
Riccardo Alfieri

Spamhaus Technology
https://www.spamhaustech.com/
Re: check_rbl digging too deep [ In reply to ]
On 25/06/19 14:42, Benny Pedersen wrote:

>
> https://docs.spamhaustech.com/10-data-type-documentation/datasets/040-zones.html
>
>
> add 9 to sbl test ?

I'd add a rule like

RCVD_IN_SBL_DROP               eval:check_rbl_sub('zen', '127.0.0.9')

With a score of at least 4

>
> possible aswell new test for authbl ?

Well AuthBL (and ZRD) are zones available to people that register with
our Data Query Service. We are just in talks with the Apache Foundation
to have our plugin that uses our new datasets added to Spamassassin.

If you are curious about DQS, it's a service that anyone can subscribe
to with a "free for most" license [1], and for which we developed a
Spamassassin plugin under Apache license that you can freely download
from
https://docs.spamhaustech.com/40-real-world-usage/SpamAssassin/000-intro.html

We have just been featured on Virus Bulletin [2], where they tested the
differences between DQS and Rsync (that are basically our public
mirrors). The difference in catch rate is quite substantial.

If anyone want to test the plugin I'll do my best to give support either
on list (that may benefit others) or our support team is available
offlist at datafeed-support@spamteq.com

[1] https://www.spamhaustech.com/data-access/
[2]
https://www.virusbulletin.com/testing/results/latest/vbspam-email-security

--
Best regards,
Riccardo Alfieri

Spamhaus Technology
https://www.spamhaustech.com/
Re: check_rbl digging too deep [ In reply to ]
On Mon, 24 Jun 2019, John Schmerold wrote:

> We had an inbound message get rejected because it was sent from a cell phone,
> shouldn't SA be checking the most recent hop? Is there a way to make this the
> default?
>
> I have this in local.cf:
> header    RCVD_IN_rbl2spamhausz   eval:check_rbl('spamhausz', 'zen.spamhaus.org.')
> score     RCVD_IN_rbl2spamhausz   3.5

I'll let others address SA issues with this, I just want to point out an
alternative:

Many sites consider Zen reliable enough for it to be used at the SMTP
level as a poison-pill DNSBL.

That would avoid any chance of it being used "too deeply"...


--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
Poor planning on your part does not create
an obligation on my part.
-----------------------------------------------------------------------
9 days until the 243rd anniversary of the Declaration of Independence
Re: check_rbl digging too deep [ In reply to ]
>On Mon, 24 Jun 2019, John Schmerold wrote:
>
>>We had an inbound message get rejected because it was sent from a
>>cell phone, shouldn't SA be checking the most recent hop? Is there a
>>way to make this the default?
>>
>>I have this in local.cf:
>>header??? RCVD_IN_rbl2spamhausz?? eval:check_rbl('spamhausz', 'zen.spamhaus.org.')
>>score???? RCVD_IN_rbl2spamhausz?? 3.5

On 25.06.19 07:52, John Hardin wrote:
>I'll let others address SA issues with this, I just want to point out
>an alternative:
>
>Many sites consider Zen reliable enough for it to be used at the SMTP
>level as a poison-pill DNSBL.
>
>That would avoid any chance of it being used "too deeply"...

no. Many people consider Zen reliable enough to reject connections from
listed IP. Deep header scanning is something very different.

--
Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Your mouse has moved. Windows NT will now restart for changes to take
to take effect. [OK]
Re: check_rbl digging too deep [ In reply to ]
On 25/06/19 17:42, Matus UHLAR - fantomas wrote:

> On 25.06.19 07:52, John Hardin wrote:
>> I'll let others address SA issues with this, I just want to point out
>> an alternative:
>>
>> Many sites consider Zen reliable enough for it to be used at the SMTP
>> level as a poison-pill DNSBL.
>>
>> That would avoid any chance of it being used "too deeply"...
>
> no.? Many people consider Zen reliable enough to reject connections from
> listed IP.? Deep header scanning is something very different.
>
ZEN is safe enough to reject at SMTP level if you can do it on your MTA
(avoiding unnecessary CPU usage by SA)

It's also useful for deep header scanning, just remember to avoid PBL
return codes when you do that :)

AuthBL also proved to be useful and doesn't create FPs even if you
weight it 80% of your required_score

--
Best regards,
Riccardo Alfieri

Spamhaus Technology
https://www.spamhaustech.com/
Re: check_rbl digging too deep [ In reply to ]
On Tue, 25 Jun 2019, Matus UHLAR - fantomas wrote:

>> On Mon, 24 Jun 2019, John Schmerold wrote:
>>
>>> We had an inbound message get rejected because it was sent from a cell
>>> phone, shouldn't SA be checking the most recent hop? Is there a way to
>>> make this the default?
>>>
>>> I have this in local.cf:
>>> header??? RCVD_IN_rbl2spamhausz?? eval:check_rbl('spamhausz',
>>> 'zen.spamhaus.org.')
>>> score???? RCVD_IN_rbl2spamhausz?? 3.5
>
> On 25.06.19 07:52, John Hardin wrote:
>> I'll let others address SA issues with this, I just want to point out an
>> alternative:
>>
>> Many sites consider Zen reliable enough for it to be used at the SMTP level
>> as a poison-pill DNSBL.
>>
>> That would avoid any chance of it being used "too deeply"...
>
> no. Many people consider Zen reliable enough to reject connections from
> listed IP. Deep header scanning is something very different.

Yes, I'm aware of that.

Rejecting up front based on the other guy's IP address is *not* deep
scanning, so there's no risk of looking *too* deeply when you're doing
that.

What I was trying to suggest is "maybe you want to use Zen as an MTA-level
DNSBL rather than as part of the SA scan." I apologize if I didn't word it
clearly.

--
John Hardin KA7OHZ http://www.impsec.org/~jhardin/
jhardin@impsec.org FALaholic #11174 pgpk -a jhardin@impsec.org
key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79
-----------------------------------------------------------------------
The ["assault weapons"] ban is the moral equivalent of banning red
cars because they look too fast. -- Steve Chapman, Chicago Tribune
-----------------------------------------------------------------------
9 days until the 243rd anniversary of the Declaration of Independence