Re: check_rbl digging too deep
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 KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@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
Re: check_rbl digging too deep
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
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, uh...@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
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 KA7OHZhttp://www.impsec.org/~jhardin/
jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@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
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-supp...@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
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
Henrik K skrev den 2019-06-25 14:16:
On Tue, Jun 25, 2019 at 11:34:33AM +, 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
On Tue, Jun 25, 2019 at 11:34:33AM +, 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
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
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_ZENeval: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, uh...@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
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
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
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
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= rejected after DATA: Call Katy Computer $
Envelope-from:
Envelope-to:
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 )
id 1hf4G0-0002xm-Vu
for kevin.somed...@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 ; Sun, 23 Jun 2019 15:18:16
+ (UTC)
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
F From: JOHN somedude
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-60d2797cc...@icloud.com>
T To: kevin.somed...@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-181212 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:
]
1.2 RCVD_IN_UCEPROTECT1 RBL: Listed in dnsbl-1.uceprotect.net
[IP 17.58.63.181 is UCEPROTECT-Level 1
listed.]
[See
]
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,
