
kai-sa-talk at conti
Feb 4, 2004, 2:34 PM
Post #1 of 1
(140 views)
Permalink
|
|
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 [at] lambertfam> 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 [at] conti>; 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 [at] incubator> 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
|