You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Cliff Hayes <ch...@afo.net> on 2010/07/16 20:31:21 UTC
disable trusted_networks and internal_networks
Hello,
Our webmail server is on the same server as sendmail and spamassassin.
I would like to filter outbound webmail but can't because the most recent
versions of spamassassin have 127.0.0.1 trusted by default.
How can I override this? Or is that a bad idea for other reasons?
Thanks in advance,
Cliff
Re: disable trusted_networks and internal_networks
Posted by Benny Pedersen <me...@junc.org>.
On lør 24 jul 2010 15:05:22 CEST, Matt Kettler wrote
[snip]
> However, 127.0.0.1 should exist. NO_RELAYS means SA interpreted the mail
> as having no origin at all, not even localhost, and that implies a
> serious lack of information being passed to SA.
sendmail -bv root
gives me a nice NO_RELAYS in spamassassin, and there might be others
that can make this with pipes output from spamassin into sendmail
where it hits it on second scan, but this does not happend if one read
describe on NO_RELAYS
all well back to "tour de france" :=)
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: disable trusted_networks and internal_networks
Posted by Matt Kettler <mk...@verizon.net>.
On 7/23/2010 10:05 AM, Benny Pedersen wrote:
> On fre 23 jul 2010 04:49:40 CEST, Matt Kettler wrote
>> Fair enough... I was keying off Benny's suggestion to lower the score of
>> both ALL_TRUSTED and NO_RELAYS, the latter of which is never a good
>> sign.
>
> as all in life it depends :=)
>
> grep NO_RELAYS /var/log/messages to see if all is accepted ham
I get no hits at all, as it should be in a working mail system.
We digress a bit from the original thread, but let me clarify:
You should never have *ANY* hits for this rule. No ham, no spam, no mail
at all. Ever. Period.
If the above grep returns any hits your server is in likely need of
configuration repair.
Even local mail should not match NO_RELAYS. Because even local mail
should have a Received: header indicating mail from 127.0.0.1 was
received by 127.0.0.1.
If it does match either:
1) your local MTA isn't adding a Received: header before the mail gets
to SpamAssassin
2) SpamAssassin can't parse the header it is parsing.
3) you have a really strange mail system where local clients don't use
the MTA at all. (rare, and highly unusual)
Either 1 or 2 is bad news and will likely cause serious accuracy problems.
>
> from mta logs, here i do auth even for 127.0.0.1 clients, that way i
> know who is the bastard :=)
Yes, I'm not saying 127.0.0.1 mail should be perfectly trusted in all
cases.
However, 127.0.0.1 should exist. NO_RELAYS means SA interpreted the mail
as having no origin at all, not even localhost, and that implies a
serious lack of information being passed to SA.
>
> no auth no problem
>
Re: disable trusted_networks and internal_networks
Posted by Benny Pedersen <me...@junc.org>.
On fre 23 jul 2010 04:49:40 CEST, Matt Kettler wrote
> Fair enough... I was keying off Benny's suggestion to lower the score of
> both ALL_TRUSTED and NO_RELAYS, the latter of which is never a good sign.
as all in life it depends :=)
grep NO_RELAYS /var/log/messages to see if all is accepted ham
from mta logs, here i do auth even for 127.0.0.1 clients, that way i
know who is the bastard :=)
no auth no problem
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: disable trusted_networks and internal_networks
Posted by Matt Kettler <mk...@verizon.net>.
On 7/20/2010 9:07 AM, Bowie Bailey wrote:
> On 7/19/2010 8:23 PM, Matt Kettler wrote:
>
>> On 7/16/2010 2:31 PM, Cliff Hayes wrote:
>>
>>> Hello,
>>>
>>> Our webmail server is on the same server as sendmail and spamassassin.
>>>
>>> I would like to filter outbound webmail but can't because the most recent
>>> versions of spamassassin have 127.0.0.1 trusted by default.
>>>
>>> How can I override this? Or is that a bad idea for other reasons?
>>>
>>>
>> As Benny suggested, you can reduce, or zero, the rule scores.
>>
>> However, that is covering up the symptoms, and you should consider
>> fixing the underlying problem.
>>
>> If you're seeing NO_RELAYS fire, there's a problem with your mail setup.
>> Period.
>>
>> It *should* be "impossible" for mail to get to SA without having any
>> Received: headers in it. Even if it is local delivery, it should have a
>> Received: header somewhere. Mail doesn't just appear out of nowhere,
>> without ever being touched by your server, and end up in SpamAssassin.
>>
>>
>> I'm concerned that either:
>> 1) your MTA isn't adding a Received: header before SA gets called
>> (sometimes a problem with hackish MTA layer integrations)
>> 2) Your MTA is adding a Received: header, but it is garbage and
>> unparsable (check for UNPARSABLE_RELAY hits)
>>
> He's asking about filtering mail from a webmail interface on the same
> server as SA. In this case, there WILL be a received header, but the IP
> will be 127.0.0.1 since the message originated with the local webmail
> instance.
>
> I don't see an easy way to do this. Webmail is trusted for the same
> reason as authenticated SMTP. It is assumed that anyone sending mail
> via these services has logged in and should therefore be trusted.
>
>
Fair enough... I was keying off Benny's suggestion to lower the score of
both ALL_TRUSTED and NO_RELAYS, the latter of which is never a good sign.
Re: disable trusted_networks and internal_networks
Posted by Bowie Bailey <Bo...@BUC.com>.
On 7/19/2010 8:23 PM, Matt Kettler wrote:
> On 7/16/2010 2:31 PM, Cliff Hayes wrote:
>> Hello,
>>
>> Our webmail server is on the same server as sendmail and spamassassin.
>>
>> I would like to filter outbound webmail but can't because the most recent
>> versions of spamassassin have 127.0.0.1 trusted by default.
>>
>> How can I override this? Or is that a bad idea for other reasons?
>>
> As Benny suggested, you can reduce, or zero, the rule scores.
>
> However, that is covering up the symptoms, and you should consider
> fixing the underlying problem.
>
> If you're seeing NO_RELAYS fire, there's a problem with your mail setup.
> Period.
>
> It *should* be "impossible" for mail to get to SA without having any
> Received: headers in it. Even if it is local delivery, it should have a
> Received: header somewhere. Mail doesn't just appear out of nowhere,
> without ever being touched by your server, and end up in SpamAssassin.
>
>
> I'm concerned that either:
> 1) your MTA isn't adding a Received: header before SA gets called
> (sometimes a problem with hackish MTA layer integrations)
> 2) Your MTA is adding a Received: header, but it is garbage and
> unparsable (check for UNPARSABLE_RELAY hits)
He's asking about filtering mail from a webmail interface on the same
server as SA. In this case, there WILL be a received header, but the IP
will be 127.0.0.1 since the message originated with the local webmail
instance.
I don't see an easy way to do this. Webmail is trusted for the same
reason as authenticated SMTP. It is assumed that anyone sending mail
via these services has logged in and should therefore be trusted.
--
Bowie
Re: disable trusted_networks and internal_networks
Posted by Matt Kettler <mk...@verizon.net>.
On 7/16/2010 2:31 PM, Cliff Hayes wrote:
> Hello,
>
> Our webmail server is on the same server as sendmail and spamassassin.
>
> I would like to filter outbound webmail but can't because the most recent
> versions of spamassassin have 127.0.0.1 trusted by default.
>
> How can I override this? Or is that a bad idea for other reasons?
>
As Benny suggested, you can reduce, or zero, the rule scores.
However, that is covering up the symptoms, and you should consider
fixing the underlying problem.
If you're seeing NO_RELAYS fire, there's a problem with your mail setup.
Period.
It *should* be "impossible" for mail to get to SA without having any
Received: headers in it. Even if it is local delivery, it should have a
Received: header somewhere. Mail doesn't just appear out of nowhere,
without ever being touched by your server, and end up in SpamAssassin.
I'm concerned that either:
1) your MTA isn't adding a Received: header before SA gets called
(sometimes a problem with hackish MTA layer integrations)
2) Your MTA is adding a Received: header, but it is garbage and
unparsable (check for UNPARSABLE_RELAY hits)
> Thanks in advance,
>
> Cliff
>
>
>
RE: disable trusted_networks and internal_networks
Posted by Benny Pedersen <me...@junc.org>.
On fre 16 jul 2010 21:23:22 CEST, Cliff Hayes wrote
> PERFECT! THANKS!
>
> You're right. I use mimedefang too.
>
> I capitalized ALL_TRUSTED and NO_RELAYS and put them in sa-mimedefang.cf and
> now everything is scanned.
>
> Thanks again :)
scan some mails like this:
spamassassin -t msg
does it works like you want for no_relays and all_trusted ?
internal_networks need to be in sync with what you have in mimedefang,
so if you like to scan mail from 127.0.0.1 then make this ip untrusted
in mimedefang should be it, and you still have default in sa
my change of scores just change that no one could benefit from being
in that network not how it works :)
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html
RE: disable trusted_networks and internal_networks
Posted by Cliff Hayes <ch...@afo.net>.
PERFECT! THANKS!
You're right. I use mimedefang too.
I capitalized ALL_TRUSTED and NO_RELAYS and put them in sa-mimedefang.cf and
now everything is scanned.
Thanks again :)
-----Original Message-----
From: Benny Pedersen [mailto:me@junc.org]
Sent: Friday, July 16, 2010 1:45 PM
To: users@spamassassin.apache.org
Subject: Re: disable trusted_networks and internal_networks
On fre 16 jul 2010 20:31:21 CEST, Cliff Hayes wrote
> How can I override this? Or is that a bad idea for other reasons?
score all_trusted 0.01
score no_relays 0.01
but as i can see you use mimedefang with have independice networking
setup for what not to scan
if its sent to mimedefang its scanned in sa
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html
Re: disable trusted_networks and internal_networks
Posted by Benny Pedersen <me...@junc.org>.
On fre 16 jul 2010 20:31:21 CEST, Cliff Hayes wrote
> How can I override this? Or is that a bad idea for other reasons?
score all_trusted 0.01
score no_relays 0.01
but as i can see you use mimedefang with have independice networking
setup for what not to scan
if its sent to mimedefang its scanned in sa
--
xpoint http://www.unicom.com/pw/reply-to-harmful.html