You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by "M. Lewis" <ca...@cajuninc.com> on 2005/12/10 01:21:45 UTC
trusted_networks
>If someone hasn't suggested it already, post your trusted_* config lines
>>along with the headers for a message that you think hit wrong, and we can
>>probably help you figure out what is going wrong. The first guess
would be
>>that you don't have trusted_networks set quite *right*, even though
you have
>>it set to *something*.
>>
>> Loren
I really didn't want to hijack the other continuing thread on this, but
I still have problems with my trusted_networks.
The only time I really notice this is when I recieve a spam that isn't
marked as such. In the case below, had it not been for the
trusted_networks, this spam would have clearly been marked as such.
In the first example, I'm using fetchmail to drag down messages from a
remote mailbox on another server. It appears to me that fetchmail is
causing this to appear as it is coming from localhost
(localhost.localdomain) and that is why _I think_ it is hitting the
ALL_TRUSTED.
Mail that comes directly into my network (not via fetchmail) I do not
believe ever has the ALL_TRUSTED as shown in the second example.
My trusted nework configs:
# Trusted
clear_trusted_networks
trusted_networks 192.168.1/24
# Internal
clear_internal_networks
internal_networks 192.168.1/24
Headers from a message where ALL_TRUSTED hit:
Return-Path: <ar...@gmail.com>
X-Original-To: cajun@localhost
Delivered-To: cajun@localhost.cajuninc.com
Received: from localhost (localhost.localdomain [127.0.0.1])
by av.cajuninc.com (Postfix) with ESMTP id 5DBEE24F59E
for <ca...@localhost>; Fri, 9 Dec 2005 18:40:25 -0500 (EST)
Received: from amavis.cajuninc.com ([127.0.0.1])
by localhost (moe.cajuninc.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 24014-04 for <ca...@localhost>;
Fri, 9 Dec 2005 18:40:06 -0500 (EST)
Received: from localhost (localhost.localdomain [127.0.0.1])
by dhcppc1.cajuninc.com (Postfix) with ESMTP
for <ca...@localhost>; Fri, 9 Dec 2005 18:40:06 -0500 (EST)
Delivered-To: cajun@cajuninc.com
Received: from mail.lizardhill.com [64.125.72.2]
by localhost with POP3 (fetchmail-6.2.5)
for cajun@localhost (single-drop); Fri, 09 Dec 2005 18:40:06 -0500 (EST)
Received: (qmail 845 invoked by uid 1279); 9 Dec 2005 23:37:07 -0000
Delivered-To: hmi@asfalto.com
Received: (qmail 832 invoked by uid 0); 9 Dec 2005 23:37:06 -0000
Received: from unknown (HELO 207.96.139.179) (unknown)
by unknown with SMTP; 9 Dec 2005 23:37:06 -0000
Message-ID: <74...@gmail.com>
From: "PrinceFelton" <ar...@gmail.com>
To: hmi@asfalto.com
Subject: Software i use
Date: Sat, 10 Dec 2005 01:32:33 +0300
X-Mailer: QUALCOMM Windows Eudora Version 5.1
MIME-Version: 1.0
Content-Type: text/html;charset=windows-1251;
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 0549-4, 2005-12-09), Outbound message
X-Antivirus-Status: Clean
X-Virus-Scanned: amavisd-new at cajuninc.com
X-Spam-Status: No, hits=4.56 tagged_above=-999 required=5
tests=[ALL_TRUSTED=-3.3, BAYES_80=2, DCC_CHECK=2.169,
DIGEST_MULTIPLE=0.098,
FORGED_MUA_EUDORA=0, FORGED_QUALCOMM_TAGS=0.489, HTML_20_30=0.226,
HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.137, MIME_HTML_ONLY=0.177,
RAZOR2_CF_RANGE_51_100=0.056, RAZOR2_CHECK=1.511, URIBL_SBL=0.996]
X-Spam-Level: ****
Status: O
X-UID: 18500
Content-Length: 224
X-Keywords:
Headers from an email that was not brought in via fetchmail:
Return-Path: <cm...@vds.net.au>
X-Original-To: cajun@cajuninc.com
Delivered-To: cajun@cajuninc.com
Received: from localhost (localhost.localdomain [127.0.0.1])
by av.cajuninc.com (Postfix) with ESMTP id 17EE424F59F
for <ca...@cajuninc.com>; Fri, 9 Dec 2005 14:15:40 -0500 (EST)
Received: from amavis.cajuninc.com ([127.0.0.1])
by localhost (moe.cajuninc.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 19390-03 for <ca...@cajuninc.com>;
Fri, 9 Dec 2005 14:15:23 -0500 (EST)
Received: from ip5452da05.adsl-surfen.hetnet.nl
(ip5452da05.adsl-surfen.hetnet.nl [84.82.218.5])
by dhcppc1.cajuninc.com (Postfix) with SMTP
for <ca...@cajuninc.com>; Fri, 9 Dec 2005 14:15:15 -0500 (EST)
Received: from vscan.hotkey.net.au
by ip5452da05.adsl-surfen.hetnet.nl (8.9.3/8.9.3) with ESMTP id
M4C3wskAyHzd
for <ca...@cajuninc.com>; Sat, 10 Dec 2005 02:01:22 -0800
Received: from 165.80.5.82
by vscan.hotkey.net.au via HTTP
for <ca...@cajuninc.com>; Sat, 10 Dec 2005 02:01:22 -0800
Date: Sat, 10 Dec 2005 02:01:22 -0800
From: Lane Meadows <cm...@vds.net.au>
Reply-To: Lane Meadows <cm...@vds.net.au>
Message-ID: <13...@vds.net.au>
To: <ca...@cajuninc.com>
Subject: *****SPAM***** Worried about not measuring up? real
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: amavisd-new at cajuninc.com
X-Spam-Status: Yes, hits=17.62 tagged_above=-999 required=5
tests=[BAYES_80=2,
FU_GEOCITIES=0.257, FU_UKGEOCITIES=5.697, ML_B_GEOCITIES=8,
SARE_SPEC_XXGEOCITIES2=1.666]
X-Spam-Level: *****************
X-Spam-Flag: YES
X-Spam-Report: Spam detection software, running on the system
"moe.cajuninc.com",
=?iso-8859-1?Q?has=0Aidentified_this_incoming_email_as_possible_spam=2E__?=
=?iso-8859-1?Q?The_original_message=0Ahas_been_attached_to_this_so_you_ca?=
=?iso-8859-1?Q?n_view_it_=28if_it_isn=27t_spam=29_or_label=0Asimilar_futu?=
=?iso-8859-1?Q?re_email=2E__If_you_have_any_questions=2C_see=0Athe_admini?=
=?iso-8859-1?Q?strator_of_that_system_for_details=2E=0A=0AContent_preview?=
=?iso-8859-1?Q?=3A__Advanced_Powermale_Pills_is_absolutely_new_and_safe__?=
=?iso-8859-1?Q?for_your_health_about=2E_It=92s_the_best_way_if_you_want_t?=
=?iso-8859-1?Q?o_make_your__pennies_bigger_and_become_a_long_player_in_se?=
=?iso-8859-1?Q?x_games_add=2E_These_pills__will_make_you_realize_that_the?=
=?iso-8859-1?Q?_saying_=93the_size_doesn=92t_matter=94_is_not__completely?=
=?iso-8859-1?Q?_true_at_all_legal=2E_=5B=2E=2E=2E=5D_=0A=0AContent_analys?=
=?iso-8859-1?Q?is_details=3A___=2817=2E6_points=2C_5=2E0_required=29=0A_p?=
=?iso-8859-1?Q?ts_rule_name______________description=0A----_-------------?=
=?iso-8859-1?Q?---------_------------------------------------------------?=
=?iso-8859-1?Q?--_5=2E7_FU=5FUKGEOCITIES_________URI=3A_FU=5FUKGEOCITIES_?=
=?iso-8859-1?Q?0=2E3_FU=5FGEOCITIES___________URI=3A_FU=5FGEOCITIES_8=2E0?=
=?iso-8859-1?Q?_ML=5FB=5FGEOCITIES_________URI=3A_ML=5FB=5FGEOCITIES_2=2E?=
=?iso-8859-1?Q?0_BAYES=5F80_______________BODY=3A_Bayesian_spam_probabili?=
=?iso-8859-1?Q?ty_is_80_to_95=25____________________________=5Bscore=3A_0?=
=?iso-8859-1?Q?=2E8857=5D_1=2E7_SARE=5FSPEC=5FXXGEOCITIES2_spamsign_point?=
=?iso-8859-1?Q?ing_to_free_webhost_spam_site=0A?=
Status: O
X-UID: 7287
Content-Length: 751
X-Keywords:
--
Life would be so much easier if we could just look at the source code.
19:05:01 up 1 day, 19:05, 4 users, load average: 0.02, 0.08, 0.03
Linux Registered User #241685 http://counter.li.org
Re: trusted_networks
Posted by jdow <jd...@earthlink.net>.
From: "jdow" <jd...@earthlink.net>
>> Mail that comes directly into my network (not via fetchmail) I do not
>> believe ever has the ALL_TRUSTED as shown in the second example.
>>
>>
>> My trusted nework configs:
>>
>> # Trusted
>> clear_trusted_networks
>> trusted_networks 192.168.1/24
>>
>> # Internal
>> clear_internal_networks
>> internal_networks 192.168.1/24
>
> Change this last to:
> ===8<---
> # Trusted
> clear_trusted_networks
> trusted_networks 192.168.1/24 127/8
>
> # Internal
> clear_internal_networks
> internal_networks 192.168.1/24
>
> ===8<---
>
> 127/8 is yourself. If you cannot trust your own mail machine who can
> you trust?
Actually strip the 192.168.1/24 off trusted_networks, too. I saved
myself a couple DNS tests by also trusting specific smarthost machines
outside my network. They don't lie even if they have a customer that
tries to spam from their network. But going to that extreme is not
really necessary.
{^_^}
Re: trusted_networks
Posted by "M. Lewis" <ca...@cajuninc.com>.
jdow wrote:
>>
>> Mail that comes directly into my network (not via fetchmail) I do not
>> believe ever has the ALL_TRUSTED as shown in the second example.
>>
>>
>> My trusted nework configs:
>>
>> # Trusted
>> clear_trusted_networks
>> trusted_networks 192.168.1/24
>>
>> # Internal
>> clear_internal_networks
>> internal_networks 192.168.1/24
>
>
> Change this last to:
> ===8<---
> # Trusted
> clear_trusted_networks
> trusted_networks 192.168.1/24 127/8
>
> # Internal
> clear_internal_networks
> internal_networks 192.168.1/24
>
> ===8<---
>
> 127/8 is yourself. If you cannot trust your own mail machine who can
> you trust?
>
> {^_^}
I recently removed the 127/8 to try to resolve the messages brought in
via fetchmail triggering the ALL_TRUSTED.
--
Software is best understood as a branch of movie making. - Ted Nelson
19:45:01 up 1 day, 19:45, 4 users, load average: 0.05, 0.22, 0.17
Linux Registered User #241685 http://counter.li.org
Re: trusted_networks
Posted by jdow <jd...@earthlink.net>.
From: "M. Lewis" <ca...@cajuninc.com>
> >If someone hasn't suggested it already, post your trusted_* config lines
> >>along with the headers for a message that you think hit wrong, and we can
> >>probably help you figure out what is going wrong. The first guess
> would be
> >>that you don't have trusted_networks set quite *right*, even though
> you have
> >>it set to *something*.
> >>
> >> Loren
>
>
>
> I really didn't want to hijack the other continuing thread on this, but
> I still have problems with my trusted_networks.
>
> The only time I really notice this is when I recieve a spam that isn't
> marked as such. In the case below, had it not been for the
> trusted_networks, this spam would have clearly been marked as such.
>
> In the first example, I'm using fetchmail to drag down messages from a
> remote mailbox on another server. It appears to me that fetchmail is
> causing this to appear as it is coming from localhost
> (localhost.localdomain) and that is why _I think_ it is hitting the
> ALL_TRUSTED.
>
> Mail that comes directly into my network (not via fetchmail) I do not
> believe ever has the ALL_TRUSTED as shown in the second example.
>
>
> My trusted nework configs:
>
> # Trusted
> clear_trusted_networks
> trusted_networks 192.168.1/24
>
> # Internal
> clear_internal_networks
> internal_networks 192.168.1/24
Change this last to:
===8<---
# Trusted
clear_trusted_networks
trusted_networks 192.168.1/24 127/8
# Internal
clear_internal_networks
internal_networks 192.168.1/24
===8<---
127/8 is yourself. If you cannot trust your own mail machine who can
you trust?
{^_^}
Re: trusted_networks
Posted by "M. Lewis" <ca...@cajuninc.com>.
Matt Kettler wrote:
> <snip>
>
> What's up with all those "Delivered-To:" headers being inserted between
> Received: headers.
>
> I suspect those are confusing SA.
>
> Really the best way to tell exactly what's up is to save one of those messages
> that false-hit ALL_TRUSTED and run it through spamassassin -D.
>
> The debug out will, among other things, tell you exactly how SA parsed each
> Received: header, and if it thinks the hosts in it are trusted or not.
>
>
>
>>Received: from unknown (HELO 207.96.139.179) (unknown)
>> by unknown with SMTP; 9 Dec 2005 23:37:06 -0000
>
>
> That's a pretty scary Received: line. At least two of those unknown's should be
> known. At absolute minimum the "by" clause should be known... eek.
My understanding is the 'unknowns' are due to some qmail anomally.
--
Software is best understood as a branch of movie making. - Ted Nelson
19:45:01 up 1 day, 19:45, 4 users, load average: 0.05, 0.22, 0.17
Linux Registered User #241685 http://counter.li.org
Re: trusted_networks
Posted by Matt Kettler <mk...@evi-inc.com>.
M. Lewis wrote:
> My trusted nework configs:
>
> # Trusted
> clear_trusted_networks
> trusted_networks 192.168.1/24
>
> # Internal
> clear_internal_networks
> internal_networks 192.168.1/24
>
> Headers from a message where ALL_TRUSTED hit:
>
<snip>
What's up with all those "Delivered-To:" headers being inserted between
Received: headers.
I suspect those are confusing SA.
Really the best way to tell exactly what's up is to save one of those messages
that false-hit ALL_TRUSTED and run it through spamassassin -D.
The debug out will, among other things, tell you exactly how SA parsed each
Received: header, and if it thinks the hosts in it are trusted or not.
> Received: from unknown (HELO 207.96.139.179) (unknown)
> by unknown with SMTP; 9 Dec 2005 23:37:06 -0000
That's a pretty scary Received: line. At least two of those unknown's should be
known. At absolute minimum the "by" clause should be known... eek.
Re: trusted_networks
Posted by mouss <us...@free.fr>.
M. Lewis a écrit :
> Maybe we should qualify that a little bit more Mouss, "maybe SA should
> not set ALL_TRUSTED if fetchmail is used and the upstream server is
> using qmail".
>
my ISP uses qmail, but provides correct Received headers. so it
shouldn't be related to qmail. I think it should be like this:
- if it finds a header that doesn't contain the "client" IP
- if this is just after a fetchmail header
then don't set ALL_TRUSTED.
> Either way, I have not been able (yet) to find a setting whereby
> mail.lizardhill.com is not trusted.
>
trusted here means it doesn't forge Received headers. now one can say
that generating buggy ones is no different for our practical purpose!
Re: trusted_networks
Posted by "M. Lewis" <ca...@cajuninc.com>.
mouss wrote:
> M. Lewis a écrit :
>
>> The only time I really notice this is when I recieve a spam that isn't
>> marked as such. In the case below, had it not been for the
>> trusted_networks, this spam would have clearly been marked as such.
>>
>> In the first example, I'm using fetchmail to drag down messages from a
>> remote mailbox on another server. It appears to me that fetchmail is
>> causing this to appear as it is coming from localhost
>> (localhost.localdomain) and that is why _I think_ it is hitting the
>> ALL_TRUSTED.
>>
>> Mail that comes directly into my network (not via fetchmail) I do not
>> believe ever has the ALL_TRUSTED as shown in the second example.
>>
>>
>> My trusted nework configs:
>>
>> # Trusted
>> clear_trusted_networks
>> trusted_networks 192.168.1/24
>>
>> # Internal
>> clear_internal_networks
>> internal_networks 192.168.1/24
>>
>> Headers from a message where ALL_TRUSTED hit:
>>
>> Return-Path: <ar...@gmail.com>
>> X-Original-To: cajun@localhost
>> Delivered-To: cajun@localhost.cajuninc.com
>> Received: from localhost (localhost.localdomain [127.0.0.1])
>> by av.cajuninc.com (Postfix) with ESMTP id 5DBEE24F59E
>> for <ca...@localhost>; Fri, 9 Dec 2005 18:40:25 -0500 (EST)
>> Received: from amavis.cajuninc.com ([127.0.0.1])
>> by localhost (moe.cajuninc.com [127.0.0.1]) (amavisd-new, port 10024)
>> with ESMTP id 24014-04 for <ca...@localhost>;
>> Fri, 9 Dec 2005 18:40:06 -0500 (EST)
>> Received: from localhost (localhost.localdomain [127.0.0.1])
>> by dhcppc1.cajuninc.com (Postfix) with ESMTP
>> for <ca...@localhost>; Fri, 9 Dec 2005 18:40:06 -0500 (EST)
>> Delivered-To: cajun@cajuninc.com
>> Received: from mail.lizardhill.com [64.125.72.2]
>> by localhost with POP3 (fetchmail-6.2.5)
>> for cajun@localhost (single-drop); Fri, 09 Dec 2005 18:40:06 -0500
>> (EST)
>
>
> running SA with -D shows the following line:
> [4785] dbg: received-header: found fetchmail marker, restarting parse
>
> so it really seems that SA is fetchmail-aware. It seems that the list of
> untrusted relays is reinitialized here. This is understandable since you
> "trust" your pop3 server.
>
>> Received: (qmail 845 invoked by uid 1279); 9 Dec 2005 23:37:07 -0000
>> Delivered-To: hmi@asfalto.com
>> Received: (qmail 832 invoked by uid 0); 9 Dec 2005 23:37:06 -0000
>> Received: from unknown (HELO 207.96.139.179) (unknown)
>> by unknown with SMTP; 9 Dec 2005 23:37:06 -0000
>
>
> but there is no info in this line for SA. so SA assumes the message was
> sent by your pop server (mail.lizardhill.com), and since you fetchmail
> it from localhost, it is trusted as well.
>
> so may be SA should not set ALL_TRUSTED if fecthmail is used and such
> buggy line is found?
Maybe we should qualify that a little bit more Mouss, "maybe SA should
not set ALL_TRUSTED if fetchmail is used and the upstream server is
using qmail".
Either way, I have not been able (yet) to find a setting whereby
mail.lizardhill.com is not trusted.
--
IBM: Insolent Bickering Mal-der-mer
01:45:02 up 3 days, 1:45, 4 users, load average: 1.65, 0.65, 0.36
Linux Registered User #241685 http://counter.li.org
Re: trusted_networks
Posted by mouss <us...@free.fr>.
M. Lewis a écrit :
> The only time I really notice this is when I recieve a spam that isn't
> marked as such. In the case below, had it not been for the
> trusted_networks, this spam would have clearly been marked as such.
>
> In the first example, I'm using fetchmail to drag down messages from a
> remote mailbox on another server. It appears to me that fetchmail is
> causing this to appear as it is coming from localhost
> (localhost.localdomain) and that is why _I think_ it is hitting the
> ALL_TRUSTED.
>
> Mail that comes directly into my network (not via fetchmail) I do not
> believe ever has the ALL_TRUSTED as shown in the second example.
>
>
> My trusted nework configs:
>
> # Trusted
> clear_trusted_networks
> trusted_networks 192.168.1/24
>
> # Internal
> clear_internal_networks
> internal_networks 192.168.1/24
>
> Headers from a message where ALL_TRUSTED hit:
>
> Return-Path: <ar...@gmail.com>
> X-Original-To: cajun@localhost
> Delivered-To: cajun@localhost.cajuninc.com
> Received: from localhost (localhost.localdomain [127.0.0.1])
> by av.cajuninc.com (Postfix) with ESMTP id 5DBEE24F59E
> for <ca...@localhost>; Fri, 9 Dec 2005 18:40:25 -0500 (EST)
> Received: from amavis.cajuninc.com ([127.0.0.1])
> by localhost (moe.cajuninc.com [127.0.0.1]) (amavisd-new, port 10024)
> with ESMTP id 24014-04 for <ca...@localhost>;
> Fri, 9 Dec 2005 18:40:06 -0500 (EST)
> Received: from localhost (localhost.localdomain [127.0.0.1])
> by dhcppc1.cajuninc.com (Postfix) with ESMTP
> for <ca...@localhost>; Fri, 9 Dec 2005 18:40:06 -0500 (EST)
> Delivered-To: cajun@cajuninc.com
> Received: from mail.lizardhill.com [64.125.72.2]
> by localhost with POP3 (fetchmail-6.2.5)
> for cajun@localhost (single-drop); Fri, 09 Dec 2005 18:40:06 -0500
> (EST)
running SA with -D shows the following line:
[4785] dbg: received-header: found fetchmail marker, restarting parse
so it really seems that SA is fetchmail-aware. It seems that the list of
untrusted relays is reinitialized here. This is understandable since you
"trust" your pop3 server.
> Received: (qmail 845 invoked by uid 1279); 9 Dec 2005 23:37:07 -0000
> Delivered-To: hmi@asfalto.com
> Received: (qmail 832 invoked by uid 0); 9 Dec 2005 23:37:06 -0000
> Received: from unknown (HELO 207.96.139.179) (unknown)
> by unknown with SMTP; 9 Dec 2005 23:37:06 -0000
but there is no info in this line for SA. so SA assumes the message was
sent by your pop server (mail.lizardhill.com), and since you fetchmail
it from localhost, it is trusted as well.
so may be SA should not set ALL_TRUSTED if fecthmail is used and such
buggy line is found?