Matus UHLAR - fantomas skrev den 2018-06-16 16:37:
not external networks. only external mail servers you trust not to
forge e-mail
headers. They may send spam but are not the spam sources.
On 16.06.18 19:06, Benny Pedersen wrote:
not correct
spamassassin need to know all wan ips your own ser
your clients (they may
be forged).
pleasee understand what it does
See quote from the wiki:
https://wiki.apache.org/spamassassin/TrustPath
set 'internal_networks' to include the hosts that act as MX for your
domains, or that may deliver mail internally in your organisation.
set &#
On 16 Jun 2018, at 16:00 (-0400), J Doe wrote:
Hi everyone,
Thank you for the feedback. I am still uncertain, however, if I have
to explicitly define the trusted_networks/internal_networks parameters
manually in my case (where SA is running on same host as MTA) ?
Ignoring the --debug I
On Sat, 16 Jun 2018 16:00:05 -0400
J Doe wrote:
> Hi everyone,
>
> Thank you for the feedback. I am still uncertain, however, if I have
> to explicitly define the trusted_networks/internal_networks
> parameters manually in my case (where SA is running on same host as
> MTA
Hi everyone,
Thank you for the feedback. I am still uncertain, however, if I have to
explicitly define the trusted_networks/internal_networks parameters manually in
my case (where SA is running on same host as MTA) ?
Ignoring the --debug I note that --lint does warn if I manually specify my
Matus UHLAR - fantomas skrev den 2018-06-16 16:37:
not external networks. only external mail servers you trust not to
forge e-mail
headers. They may send spam but are not the spam sources.
not correct
spamassassin need to know all wan ips your own servers use, it does not
need to protect fo
Matus UHLAR - fantomas skrev den 2018-06-16 18:07:
On 16.06.18 10:12, David Jones wrote:
That is basically the same thing worded a little differently. If you
have an internal mail relay and your SA server has a private IP on it,
then that will be an RFC 1918 IP or range in your internal_netwo
On 06/15/2018 05:44 PM, J Doe wrote:
Jun 15 18:39:23.422 [8422] dbg: config: trusted_networks
are not configured; it is recommended that you configure
trusted_networks manually
My question is:
— Should I manually set trusted_networks to have the IP address
of the host it is running on
On 06/16/2018 09:37 AM, Matus UHLAR - fantomas wrote:
On 06/15/2018 05:44 PM, J Doe wrote:
Jun 15 18:39:23.422 [8422] dbg: config: trusted_networks are not
configured; it is recommended that you configure trusted_networks
manually
My question is:
— Should I manually set trusted_networks
On 06/15/2018 05:44 PM, J Doe wrote:
Jun 15 18:39:23.422 [8422] dbg: config: trusted_networks are not
configured; it is recommended that you configure trusted_networks manually
My question is:
— Should I manually set trusted_networks to have the IP address of the host it
is running on
On 06/16/2018 06:33 AM, David Jones wrote:
On 06/15/2018 05:44 PM, J Doe wrote:
Hello,
I am currently using SpamAssassin 3.4.1 on Ubuntu Linux 16.04.4 LTS.
I have SA running on a server with Postfix as the MTA on the same server.
I have a question regarding the trusted_networks
On 06/15/2018 05:44 PM, J Doe wrote:
Hello,
I am currently using SpamAssassin 3.4.1 on Ubuntu Linux 16.04.4 LTS. I have SA
running on a server with Postfix as the MTA on the same server.
I have a question regarding the trusted_networks configuration parameter (man
Mail::SpamAssassin::Conf
J Doe skrev den 2018-06-16 00:44:
$ spamassassin --debug --lint
--config-file=/etc/spamassassin/local.custom.cf
dont use --lint and --config-file at same time to do lint testing
if this is a error, please create a bug
--debug does not make it more simple, and mostly only developpers know
Hello,
I am currently using SpamAssassin 3.4.1 on Ubuntu Linux 16.04.4 LTS. I have SA
running on a server with Postfix as the MTA on the same server.
I have a question regarding the trusted_networks configuration parameter (man
Mail::SpamAssassin::Conf). I manually added this to a custom
On Thu, 15 Mar 2018 18:08:50 -0700 (PDT)
Dan Mahoney (Gushi) wrote:
> Hey there,
>
> I'm seeing conflicting information about what
> trusted_networks/internal_networks means.
...
> Here's my problem with the somewhat unclear docs:
> (https://wiki.apache.org/spama
On 03/15/2018 08:08 PM, Dan Mahoney (Gushi) wrote:
Hey there,
I'm seeing conflicting information about what
trusted_networks/internal_networks means.
One of $dayjob's emails tripped off our internal spamassassin, which was
scanning outbound mail as well. Apparently we used a
Hey there,
I'm seeing conflicting information about what
trusted_networks/internal_networks means.
One of $dayjob's emails tripped off our internal spamassassin, which was
scanning outbound mail as well. Apparently we used a URL in our mail
(talking about a security issue) and ca
On Sat, 17 Dec 2016 20:51:01 +0100
Marcus Schopen wrote:
> > SpamAssassin usually deals with this problem by looking for
> > authentication in the header, but that's not recorded here.
>
> There is no auth hint in the header when using the submission server.
>
> Received: from [192.168.178.25
Hi,
Am Samstag, den 17.12.2016, 13:17 + schrieb RW:
> On Fri, 16 Dec 2016 22:41:49 +0100
> Marcus Schopen wrote:
>
>
> > The problem is, that smtp-out.myoffice.de is also a submission server
> > for dialup clients. Headers from to to down:
> >
> > Received: from smtp-out.myoffice.de by MY_S
On Fri, 16 Dec 2016 22:41:49 +0100
Marcus Schopen wrote:
> The problem is, that smtp-out.myoffice.de is also a submission server
> for dialup clients. Headers from to to down:
>
> Received: from smtp-out.myoffice.de by MY_SERVER_IP
> Received: from dialup-client-IP by smtp-out.myoffice.de
SpamA
Hi,
I have configuration problems with trusted_networks and
internal_networks when forwarding my office mails to my private server,
because one server in the trust chain is also a submission server.
My current setup is simple (SA runs on my private server =
MY_SERVER_IP):
trusted_networks
On Sat, 10 Sep 2016 11:13:02 + (UTC)
Pedro David Marco wrote:
>
> i have this in my local.cf:
>
> trusted_networks 88.2.89.3
> ...
> [17721] dbg: received-header: relay 88.2.89.3 trusted? no
> internal? no msa? no
>
> is this normal?
It
Ops... sorry it's a typo...
i have this in my local.cf:
trusted_networks 88.2.89.3
when i run SA in debug mode i see this:
[17721] dbg: received-header: relay 88.2.89.3 trusted? no internal? no msa?
no
there is no error or warns anywhere...
is this n
From: Pedro David Marco [mailto:pedrod_ma...@yahoo.com]
Sent: Saturday, September 10, 2016 9:51 AM
To: users@spamassassin.apache.org
Subject: trusted_networks question...
Hi there...
i have this in my local.cf:
trusted_networks88.2.890.3
Hi there...
i have this in my local.cf:
trusted_networks 88.2.890.3
when i run SA in debug mode i see this:
[17721] dbg: received-header: relay 88.2.890.3 trusted? no internal? no msa? no
there is no error or warns anywhere...
is this normal?
Thanks!
---PedroD
I'm using Mail::SpamAssassin as part of the tool chain for managing
dnswl.org data - basically to verify spam samples.
I would like to add trusted_networks configurations programmatically, ie
without having to write them to a config file first.
What I currently have (reduced to the bare mi
> running on our MXes via a milter and since SA (and these boxes) only
> see MX traffic, trusted_networks and/or internal_networks are empty.
> This causes the whitelist_from_rcvd to never fire.
>
> Our MTA does construct a synthetic "Received" header
>
> My question
Xes
via a milter and since SA (and these boxes) only see MX traffic,
trusted_networks and/or internal_networks are empty. This causes the
whitelist_from_rcvd to never fire.
Our MTA does construct a synthetic "Received" header as it passes the message
to SA via the milter interface.
would like to use whitelist_from_rcvd as the envelope from
(RFC5321.MailFrom) and sending system is not exactly static, but close
enough that the globing should work. The issue is that SA is running on
our MXes via a milter and since SA (and these boxes) only see MX traffic,
trusted_networks
Matus UHLAR - fantomas skrev den 2014-07-13 17:14:
What do I (or the others) miss here?
On 13.07.14 18:27, Benny Pedersen wrote:
i yet to see that pbl ips with smtp auth here
any dynamic - dialup, DSL, cable ... ?
they are supposed to use authentication and should not get
RCVD_IN_SORBS_DU
, not smtp
auth faults
i think this patch is completely unnedded if trusted_networks and
internal_networks is doing its job
smtp auth gets all_trusted, and system users get no_relays
i yet to see that pbl ips with smtp auth here
Matus UHLAR - fantomas skrev den 2014-07-13 12:30:
isn't the whole point of authentication to avoid scanning the
authenticated
IP in blacklists?
On 13.07.14 15:04, Benny Pedersen wrote:
that would be a fault, since when its sent via smtps or submission it
would be in trusted_net
Matus UHLAR - fantomas skrev den 2014-07-13 12:30:
isn't the whole point of authentication to avoid scanning the
authenticated
IP in blacklists?
that would be a fault, since when its sent via smtps or submission it
would be in trusted_networks, but blindly think this is not spam is
an
On 11.07.14 22:20, Nick I wrote:
I implemented your patch, but unfortunatelly it did not work for me.
Authenticated sender IP address was recognised as trusted.
I still need to have 'smtpd_sasl_authenticated_header = yes' in my postfix
so i commented out these 3 lines.
I still don't understa
Kevin A. McGrail :
> On 7/10/2014 5:55 PM, Giampaolo Tomassoni wrote:
>
>> Il 2014-07-10 17:36 Nick I ha scritto:
>>
>> Hi
>>>
>>> In the following example our mx received message with ESMTPSA from
>>> 1.1.1.1 and that ip detected as trusted.
&g
On 7/10/2014 5:55 PM, Giampaolo Tomassoni wrote:
Il 2014-07-10 17:36 Nick I ha scritto:
Hi
In the following example our mx received message with ESMTPSA from
1.1.1.1 and that ip detected as trusted.
Our trusted_networks list do not have this ip configured.
I need to run rbl check against
On 10.07.14 18:36, Nick I wrote:
In the following example our mx received message with ESMTPSA from 1.1.1.1
and that ip detected as trusted.
Our trusted_networks list do not have this ip configured.
I need to run rbl check against 1.1.1.1.
Is there any settings to not add authenticated host to
Il 2014-07-10 17:36 Nick I ha scritto:
Hi
In the following example our mx received message with ESMTPSA from
1.1.1.1 and that ip detected as trusted.
Our trusted_networks list do not have this ip configured.
I need to run rbl check against 1.1.1.1.
Is there any settings to not add
Hi
In the following example our mx received message with ESMTPSA from 1.1.1.1
and that ip detected as trusted.
Our trusted_networks list do not have this ip configured.
I need to run rbl check against 1.1.1.1.
Is there any settings to not add authenticated host to trusted hosts ?
We use
itelist email adresses, not IPs. And it worked time ago (I
guess it worked until I changed trusted_networks).
Helmut Schneider skrev den 2013-03-13 15:19:
How can I whiltelist(_auth) senders now?
if sender ip is whitelisted, does it then make sense to whitelist based
on dkim/spf ?
note here dkim is not using ip at all
Hi,
after a discussion here on September 12th I added MessageLabs to
trusted_networks. If I understood posts in the net correctly this might
be the reason why whitelist_ does not work anymore.
Mar 13 14:44:04.119 [17641] dbg: spf: relayed through one or more
trusted relays, cannot use header
On Mon, 12 Mar 2012 12:44:43 -0700 (PDT)
Alain Tesio wrote:
>
> Thanks for your help,
>
> > > Hi,
> > >
> > > I'm using spamassassin 3.2.5 with Exim at smtp time on Debian.
> > >
> > > I'm trying to whitelist a single IP and s
Thanks for your help,
> > Hi,
> >
> > I'm using spamassassin 3.2.5 with Exim at smtp time on Debian.
> >
> > I'm trying to whitelist a single IP and set trusted_networks to this
> > IP in local.cf
>
> That's not the same whitelisting.
On Mon, 12 Mar 2012 05:26:01 -0700 (PDT)
Alain Tesio wrote:
>
> Hi,
>
> I'm using spamassassin 3.2.5 with Exim at smtp time on Debian.
>
> I'm trying to whitelist a single IP and set trusted_networks to this
> IP in local.cf
That's not the same whitelistin
On 12.03.12 05:26, Alain Tesio wrote:
I'm using spamassassin 3.2.5 with Exim at smtp time on Debian.
old SA on apparently outdated, unsupported debian.
I'm trying to whitelist a single IP and set trusted_networks to this IP in
local.cf
It's not working, whereas other settin
Hi,
I'm using spamassassin 3.2.5 with Exim at smtp time on Debian.
I'm trying to whitelist a single IP and set trusted_networks to this IP in
local.cf
It's not working, whereas other settings in this file are handled correctly.
In the logs, I see that all logs have "r
> Probably hit by a bug in NetAddr::IP, see:
>
> https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6681
>
> Upgrade it to NetAddr-IP-4.055 or downgrade to 4.048.
Bingo! I upgraded to 4.056 and no more problem!
Apparently there'a a workaround, too, mentioned
in comment 20 above:
4.05
On 07.11.11 08:19, spamassas...@horizon.com wrote:
For some reason, spamassassin thinks that 0/0 is trusted, even after my
most strenuous attempts to dissuade it:
$ grep _networks /etc/spamassassin/*
/etc/spamassassin/local.cf:# trusted_networks 212.17.35.
/etc/spamassassin
On Mon, 7 Nov 2011 14:31:53 +0100, Mark Martinec wrote:
Upgrade it to NetAddr-IP-4.055 or downgrade to 4.048.
latest is 4.056
just cant find the line with 0/0 here :(
> For some reason, spamassassin thinks that 0/0 is trusted, even after my
> most strenuous attempts to dissuade it:
>
> $ grep _networks /etc/spamassassin/*
> /etc/spamassassin/local.cf:# trusted_networks 212.17.35.
> /etc/spamassassin/local.cf:clear_trusted_networks
&
On 7 Nov 2011 08:19:43 -0500, spamassas...@horizon.com wrote:
[snip]
The question, of course, is "WTF?"
no, what line is 0/0 in ?
are you sure that computer is not haveing ipv6 ? :=)
For some reason, spamassassin thinks that 0/0 is trusted, even after my
most strenuous attempts to dissuade it:
$ grep _networks /etc/spamassassin/*
/etc/spamassassin/local.cf:# trusted_networks 212.17.35.
/etc/spamassassin/local.cf:clear_trusted_networks
/etc/spamassassin
On Mon, 10 Oct 2011 13:14:21 +0200 (CEST), Tomas Macek wrote:
OK, this should be good:
trusted_networks 213.0.0.5 213.0.0.10 # primary mx IP and backup
mx IP
internal_networks 213.0.0.5 # only the IP of primary mx
Right?
On 10.10.11 16:40, Benny Pedersen wrote:
backup is
On 10.10.11 13:14, Tomas Macek wrote:
OK, this should be good:
trusted_networks 213.0.0.5 213.0.0.10 # primary mx IP and backup mx IP
internal_networks 213.0.0.5 # only the IP of primary mx
Right?
No. All the backup MX servers must be in internal_networks too
I know
On Tue, 11 Oct 2011 07:37:53 +0200 (CEST), Tomas Macek wrote:
[snip]
No, there is not ALL_TRUSTED in the headers. I'm sorry, I did not
write here the rules that matched the message, so here it is:
X-Spam-Status: Yes, score=5.988 tagged_above=3 required=5
tests=[DOS_OE_TO_MX=3.086, FSL_H
On Mon, 10 Oct 2011, Benny Pedersen wrote:
On Mon, 10 Oct 2011 13:14:21 +0200 (CEST), Tomas Macek wrote:
On Mon, 10 Oct 2011, Benny Pedersen wrote:
On Mon, 10 Oct 2011 12:19:56 +0200 (CEST), Tomas Macek wrote:
I suggest something like this:
trusted_networks 213.x.x.x/y # all our public ip
On Mon, 10 Oct 2011 13:14:21 +0200 (CEST), Tomas Macek wrote:
On Mon, 10 Oct 2011, Benny Pedersen wrote:
On Mon, 10 Oct 2011 12:19:56 +0200 (CEST), Tomas Macek wrote:
I suggest something like this:
trusted_networks 213.x.x.x/y # all our public ip addresses range
internal_networks 213.0.0.5
il from internal network 213.x.x.x/y from his public
> static IP through our mailserver into some mailbox hosted on our mailserver.
> I think I must have some misconfiguration in spamassassin...
I believe the right variable to set up would be "msa_networks" instead of
"tr
On Mon, 10 Oct 2011, Benny Pedersen wrote:
On Mon, 10 Oct 2011 12:19:56 +0200 (CEST), Tomas Macek wrote:
I suggest something like this:
trusted_networks 213.x.x.x/y # all our public ip addresses range
internal_networks 213.0.0.5 # let's say that's our mailserver's IP
the ab
On Mon, 10 Oct 2011 12:19:56 +0200 (CEST), Tomas Macek wrote:
I suggest something like this:
trusted_networks 213.x.x.x/y # all our public ip addresses range
internal_networks 213.0.0.5 # let's say that's our mailserver's IP
the above should only list all the mailserver(s)
d outgoing
mail traffic to/from all of our domains. We are ISP.
Our customer complained about false positive mail with DOS_OE_TO_MX.
How exactly this rule works? Should I add all my range 213.x.x.x/y to the
trusted_networks and my mailserver should be added to the
internal_networks?
I guess
On Mon, 2010-10-18 at 12:12 -0400, dar...@chaosreigns.com wrote:
> On 10/18, Karsten Bräckelmann wrote:
> > So you're calling this without evidence, and actually even without
> > suspicion.
> I did check the ruleqa details on a few relevant tests first. The results
> are very inconsistent between
On 10/18, Karsten Bräckelmann wrote:
> So you're calling this without evidence, and actually even without
> suspicion.
>
> What about doing at least some minimal research first? You could check
> ruleqa results.
Why are you arguing with me? I just thought there was enough possibility
of this bei
On Sun, 2010-10-17 at 23:28 -0400, dar...@chaosreigns.com wrote:
> On 10/18, Karsten Bräckelmann wrote:
> > Ahem. Let us do this the other way round. *Why* do you believe this is
> > warranted, *why* do you believe our mass-check contributors might have
> > their internal and trusted networks set u
On Sun, 17 Oct 2010, dar...@chaosreigns.com wrote:
I don't know that there's any way to centrally verify that those who
are uploading masscheck results are performing their masschecks on a
properly-configured system.
To my knowledge there is not. I'm asking that each of the submitters
verify
On 10/18, Karsten Bräckelmann wrote:
> Ahem. Let us do this the other way round. *Why* do you believe this is
> warranted, *why* do you believe our mass-check contributors might have
> their internal and trusted networks set up incorrectly? This is crucial.
I'm not confident there is a problem. T
On Sun, 2010-10-17 at 22:18 -0400, dar...@chaosreigns.com wrote:
> > > Could it be verified that the corpora being submitted for the weekly
> > > Network Mass-Checks are coming from systems with correctly configured
> > > trusted_networks and internal_networks? [...]
&
On 10/17, John Hardin wrote:
> The SA results within the submitted corpora themselves (if present in the
> first place) are ignored by the centralized nightly masscheck testing.
> Your concern is only valid for those who are doing local masschecks on
> private corpora and uploading the results
On Sun, 17 Oct 2010, dar...@chaosreigns.com wrote:
Could it be verified that the corpora being submitted for the weekly
Network Mass-Checks are coming from systems with correctly configured
trusted_networks and internal_networks?
The SA results within the submitted corpora themselves (if
Could it be verified that the corpora being submitted for the weekly
Network Mass-Checks are coming from systems with correctly configured
trusted_networks and internal_networks? It's important for some of the
rules, and verifying it works seems inconvenient enough that it might have
been sk
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
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
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
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
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 tru
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 i
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 l
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 w
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 s
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 advanc
On 3/29/2010 11:40 AM, Kaleb Hosie wrote:
> I'm having a problem with the trusted_networks option. Right now I have it
> set to:
>
> trusted_networks 10.0.1/24
>
> In postfix, I need to have spamassassin listed under
> "smtpd_recipient_restrictions" so th
> On 29.3.2010 18:40, Kaleb Hosie wrote:
> > I'm having a problem with the trusted_networks option.
> Right now I have it set to:
> >
> > trusted_networks 10.0.1/24
> >
> > In postfix, I need to have spamassassin listed under
> "smtpd_recipient_r
On Mon, 2010-03-29 at 11:40 -0400, Kaleb Hosie wrote:
> I'm having a problem with the trusted_networks option. Right now I have
> it set to:
>
> trusted_networks 10.0.1/24
> When I try to use this option; I login through telnet port 25, and send
> the test spam string (f
On 29.3.2010 18:40, Kaleb Hosie wrote:
> I'm having a problem with the trusted_networks option. Right now I have it
> set to:
>
> trusted_networks 10.0.1/24
>
> In postfix, I need to have spamassassin listed under
> "smtpd_recipient_restrictions" so th
I'm having a problem with the trusted_networks option. Right now I have it set
to:
trusted_networks 10.0.1/24
In postfix, I need to have spamassassin listed under
"smtpd_recipient_restrictions" so that it will only scan incoming emails
however it would be handy to get this op
On Tue, 2010-03-02 at 10:32 -0500, dar...@chaosreigns.com wrote:
> If you have spamassassin's trusted_networks value configured properly, this
> module will now always report the correct IP to DNSWL when you run
> spamassassin --report.
>
> trusted_networks needs to be right f
If you have spamassassin's trusted_networks value configured properly, this
module will now always report the correct IP to DNSWL when you run
spamassassin --report.
trusted_networks needs to be right for all DNS Blacklist checks (and DNSWL)
to know which IP to check. Mine currently looks
On Sun, 2009-08-09 at 00:56 +0100, RW wrote:
> > Also, I'm still not sure I have my trusted_networks setting correct. I
> > have this in my local.cf:
> >
> > trusted_networks 192.168/16 71.48.160.0/20 71.54.96/19
> >
> > Here is a line of Received
On Sun, 2009-08-09 at 00:56 +0100, RW wrote:
> The trouble with whitelist_from_rcvd is that it relies on the MX server
> recording reverse DNS - most do, some don't.
>
>
> > Also, I'm still not sure I have my trusted_networks setting correct. I
g
> shouldn't I get a hit on USER_IN_WHITELIST or not?
The trouble with whitelist_from_rcvd is that it relies on the MX server
recording reverse DNS - most do, some don't.
> Also, I'm still not sure I have my trusted_networks setting correct. I
> have this in my local.cf:
>
&
l not sure I have my trusted_networks setting correct. I
have this in my local.cf:
trusted_networks 192.168/16 71.48.160.0/20 71.54.96/19
Here is a line of Received: from headers from a test mail to myself:
Received: from [71.54.109.114] and one from someone else using embarq
Received: from [71.48.166.180]
On Tue, July 14, 2009 21:26, Jari Fredriksson wrote:
> Duh. Dumb. Arrgh! Hit! Damn.
its rocket science :)
--
xpoint
Jari Fredriksson a écrit :
>> [snip]
>> when I put your lines in my config, I only seethe
>> 127.0.0.1/32 warning.
>>
>
>>>
>>> It looks like SA itself configured the trusted.
>
> I removed both the 127.0.0.1 AND 10/8 and this is happy again. It seems to
> configure the internal networks as tru
> Jari Fredriksson a écrit :
>> I tried with this:
>>
>> -(local.cf)---
>>
>> internal_networks 10.0.0.0/8
>> trusted_networks 10.0.0.0/8 127.0.0.1
>> trusted_networks 212.16.98.0/24 212.16.100.0/24
>> 62.142.0.0/16 195.197.172
> Jari Fredriksson a écrit :
>> I tried with this:
>>
>> -(local.cf)---
>>
>> internal_networks 10.0.0.0/8
>> trusted_networks 10.0.0.0/8 127.0.0.1
>> trusted_networks 212.16.98.0/24 212.16.100.0/24
>> 62.142.0.0/16 195.197.172
Jari Fredriksson a écrit :
> I tried with this:
>
> -(local.cf)---
>
> internal_networks 10.0.0.0/8
> trusted_networks 10.0.0.0/8 127.0.0.1
> trusted_networks 212.16.98.0/24 212.16.100.0/24 62.142.0.0/16 195.197.172.98
> trusted_networks 195.74
On Tue, July 14, 2009 14:48, Jari Fredriksson wrote:
> Yeah. My LAN is using 10/8 for hysterical reasons. Is there something wrong
> here?
just that your source have now rfc1918 ranges hardcorded into sa, so remove
your own internal/trsuted/msa for rfc1918 will solve it
ps: i have not seen the
Jari Fredriksson wrote:
I tried with this:
-(local.cf)---
internal_networks 10.0.0.0/8
trusted_networks 10.0.0.0/8 127.0.0.1
trusted_networks 212.16.98.0/24 212.16.100.0/24 62.142.0.0/16 195.197.172.98
trusted_networks 195.74.0.0/16 213.192.189.2/24 217.30.188.0/24 65.54.0.0/16
> On Tue, July 14, 2009 13:25, Jari Fredriksson wrote:
>
>> [7594] warn: netset: cannot include 127.0.0.1/32 as it
>> has already been included [7594] warn: netset: cannot
>> include 10.0.0.0/8 as it has already been included It
>> looks like SA itself configured the trusted.
>
> rfc1918
>
Yea
1 - 100 of 362 matches
Mail list logo
