Mailing List Archive

trsuted_networks and num_check_received, was: why is RCVD_IN_NJABL_DIALUP score so high?
On 2/3/2004 at 5:36 PM, "Scott Lambert" <lambert@lambertfam.org> wrote:

> On Tue, Feb 03, 2004 at 10:18:32PM +0100, Andy Spiegl wrote:
>> > Or better, skip spamassassin processing altogether for SMTP AUTH
>> > connections (if possible)
>>
>> But _everyone_ using spamassassin in the whole world would have to do
>> that. Otherwise my and my users mails get sorted out because they
>> were sent from a dial-up IP pool.

> These rules aren't supposed to fire if the dialup was the first hop and
> not the hop that was talking to your "trusted" mail server which is
> running spamassassin.

SA 2.61 here, and these are really two separate, but connected
problems: 'trusted_networks' and 'whitelist_from_rcvd' on one
side, and 'num_check_received' preventing FPs on DNSBLs matching
dialups in the headers on the other side.

Seemingly:
1) - the first hop is not trusted if you run Sendmail. Indeed, even
if you make your own receiving MTA host's IP trusted, this does not
make the first Received: line trusted as it probably should be:
Example:
Received: from mail.apache.org (daedalus.apache.org [208.185.179.12])
by conti.nu (8.12.10/8.12.10) with SMTP id i13MvmQi028269
for <munged_satalk_20040204@conti.nu>; Tue, 3 Feb 2004 17:57:53 -0500 (EST)

conti.nu = 208.241.101.2 = trusted by way of 'trusted_networks'
The daedalus.apache.org has FCrDNS as indicated by the format of
the Received: line, but is not trusted (visible via -D debug)

Why we can't implicitly trust the first Received: line showing FCrDNS
hostnames of the directly-connecting client is beyond me: the way
this is right now, any single host/network that one wishes to refer to
via whitelist_from_rcvd has to be set up as a trusted host/network:
this does not scale.
And it still doesn't work correctly after that:
whitelist_from_rcvd *@incubator.apache.org apache.org
does not work right now, with 2.61.
This SHOULD match a Received line like the above one, and the MAIL FROM:
envelope address, which is something like: Return-Path: \
<spamassassin-users-return-nnnn-localpart=example.com@incubator.apache.org>
See also:
http://bugzilla.spamassassin.org/show_bug.cgi?id=2738

2) The num_check_received option seems highly useful, as it limits
the number of Received: lines queried against DNSBLs.
It's marked "deprecated in version 2.60 and later", but would
someone please explain to me why?
- it prevents DoS'ing SA by feeding it a large (15-25) number
of forged Received: lines and resulting long DNSBL lookups
- it precisely controls how many Received: lines you want to
include in the DNSBL checks: In the ideal case, that's exactly
ONE, as all others can't be trusted, and eliminates said FP
DYNABLOCK/SORBS hits that are inevitably somewhere down in
the header.

bye,Kai


--
"Just say No" to Spam Kai Schlichting
New York, Palo Alto, You name it Sophisticated Technical Peon
Kai's SpamShield <tm> is FREE! http://www.SpamShield.org
| |
LeasedLines-FrameRelay-IPLs-ISDN-PPP-Cisco-Consulting-VoiceFax-Data-Muxes
WorldWideWebAnything-Intranets-NetAdmin-UnixAdmin-Security-ReallyHardMath