soon so please save the
chastisements. I'm stuck with it for now.
ALL - running the emails through Spamassassin via the command line does NOT
fire the ALL_TRUSTED flag so I am left to believe the issue is with Amavis. I
am not using milter. Ubuntu says Amavis is already at the latest version
On 24.06.23 02:12, Denny Jones via users wrote:
Spamassassin Version: 3.4.2Amavisd-new Vrsion: 2.7.1
ALL_TRUSTED is always in every header:Here's an example header:
On 6/25/2023 9:23 AM, Matus UHLAR - fantomas wrote:
do you use amavisd-milter?
There's bug in older versions
On 6/25/2023 9:23 AM, Matus UHLAR - fantomas wrote:
On 24.06.23 02:12, Denny Jones via users wrote:
Spamassassin Version: 3.4.2Amavisd-new Vrsion: 2.7.1
ALL_TRUSTED is always in every header:Here's an example header:
do you use amavisd-milter?
There's bug in older versions
On 24.06.23 02:12, Denny Jones via users wrote:
Spamassassin Version: 3.4.2Amavisd-new Vrsion: 2.7.1
ALL_TRUSTED is always in every header:Here's an example header:
do you use amavisd-milter?
There's bug in older versions of amavis describes here:
https://gitlab.com/amavis/amavis/-
On 2023-06-23 at 22:12:50 UTC-0400 (Sat, 24 Jun 2023 02:12:50 +
(UTC))
Denny Jones via users
is rumored to have said:
Hello,
Spamassassin Version: 3.4.2Amavisd-new Vrsion: 2.7.1
ALL_TRUSTED is always in every header:Here's an example header:
[snip]
I have both internal_network
Hello,
Spamassassin Version: 3.4.2Amavisd-new Vrsion: 2.7.1
ALL_TRUSTED is always in every header:Here's an example header:
Return-Path: <360-kci-804.0.1049843.0.0.170139.9.7679...@bounce.info.adobe.com>
Delivered-To:
Received: from localhost (localhost [127.0.0.1])
On 5 Jul 2019, at 12:31, David Jones wrote:
On 7/5/19 9:55 AM, Bill Cole wrote:
On 5 Jul 2019, at 10:30, David Jones wrote:
On 7/5/19 9:09 AM, Bill Cole wrote:
On 5 Jul 2019, at 9:37, David Jones wrote:
I believe the only change would be the Relay-Countries value would
have
country code
nge)
> boundary_networks = works like trusted_networks except:
>
> 1. X-Relay-Countries will be populated
> 2. ESMTPA IP not included in ALL_TRUSTED
>
> Then we don't need to add new headers and no new rules to manage.
As I said in another post, it doesn't make sense to
used to check for hacked
> local users coming in from unexpected countries.
>
Perhaps we need something added like a 3rd option like boundary_networks
as an authentication boundary beyond trusted_networks?
internal_networks = in our admin control and won't forge headers
trusted_n
On Fri, Jul 05, 2019 at 04:31:01PM +, David Jones wrote:
>
> Perhaps we need something added like a 3rd option like boundary_networks?
>
> internal_networks = in our admin control and won't forge headers
> trusted_networks = trust to not forge headers (no change)
> boundary_networks = works ju
On Fri, Jul 05, 2019 at 07:30:11PM +0300, Henrik K wrote:
> X-Relay-Countries-Auth _RELAYCOUNTRYAUTH_
>Auth will contain all relays starting from the first relay that used
>authentication. For example, this could be used to check for hacked
>local users coming in from unexpected c
pletely overlap.
1. Trusted to not forge the Received or X-Originating-IP headers.
2. Both make up the ALL_TRUSTED rule hit and include the authenticated
ESMTPA which can include spam from a compromised account.
My servers are my problem to detect and handle compromised accounts. I
can contro
On Fri, Jul 05, 2019 at 03:59:41PM +, David Jones wrote:
> My understanding of the proposed X-Relay-Countries-MUA would be
> identical to the current X-Relay-Countries except when there is an
> authenticated MSA, then it would show the country code.
I've never even thought of this, since it
On 7/5/19 9:51 AM, Henrik K wrote:
> On Fri, Jul 05, 2019 at 02:46:16PM +, David Jones wrote:
>>
>> I am completely OK with switching to a new X-Relay-Countries-MUA header
>> as long as it works just like the current X-Relay-Countries when there
>> is no MUA. If it's differnt logic or an extra
esting changing any other logic so
the ALL_TRUSTED would still hit and RBLs would not be check on
authenticated IPs.
Is your concern the RBL checks on those authenticated IPs?
No. My concern is about changing what is in Relay-Countries.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA
On Fri, Jul 05, 2019 at 02:46:16PM +, David Jones wrote:
>
> I am completely OK with switching to a new X-Relay-Countries-MUA header
> as long as it works just like the current X-Relay-Countries when there
> is no MUA. If it's differnt logic or an extra header to check, then
> that would m
On 7/5/19 9:36 AM, Henrik K wrote:
> On Fri, Jul 05, 2019 at 02:32:42PM +, David Jones wrote:
>> On 7/5/19 9:03 AM, Henrik K wrote:
>>> On Fri, Jul 05, 2019 at 01:37:50PM +, David Jones wrote:
For the sake of others, it would be beneficial if the default behavior
of X-Relay-C
On Fri, Jul 05, 2019 at 02:32:42PM +, David Jones wrote:
> On 7/5/19 9:03 AM, Henrik K wrote:
> > On Fri, Jul 05, 2019 at 01:37:50PM +, David Jones wrote:
> >>
> >> For the sake of others, it would be beneficial if the default behavior
> >> of X-Relay-Countries changed to the X-Relay-Countr
On 7/5/19 9:03 AM, Henrik K wrote:
> On Fri, Jul 05, 2019 at 01:37:50PM +, David Jones wrote:
>>
>> For the sake of others, it would be beneficial if the default behavior
>> of X-Relay-Countries changed to the X-Relay-Countries-MSA.
>
> I renamed it X-Relay-Countries-MUA since it's more descri
se substantial false
> positives at some sites if deployed without carefully considered
> preparation. It would be a poison pill for packagers who value stability.
>
>
I believe the only change would be the Relay-Countries value would have
country codes in it. We aren't sug
On 5 Jul 2019, at 9:37, David Jones wrote:
For the sake of others, it would be beneficial if the default behavior
of X-Relay-Countries changed to the X-Relay-Countries-MSA.
Definitely not for 3.4.3. Preferably not at all. While I agree in
principle with having some way to trust machines as ho
On Fri, Jul 05, 2019 at 01:37:50PM +, David Jones wrote:
>
> For the sake of others, it would be beneficial if the default behavior
> of X-Relay-Countries changed to the X-Relay-Countries-MSA.
I renamed it X-Relay-Countries-MUA since it's more describing. It lists all
after the MSA itself.
ers, it would be beneficial if the default behavior
of X-Relay-Countries changed to the X-Relay-Countries-MSA. That
shouldn't be too much of a change to cause adverse effects since it
would still be hitting ALL_TRUSTED and no RBL checks happen. If the
RelayCountry.pm plugin was not enabled (default?) then this would result
in no change for the majority of SA instances and only enhance those
that have enabled it.
--
David Jones
On Fri, Jul 05, 2019 at 09:50:35AM +0300, Henrik K wrote:
> On Fri, Jul 05, 2019 at 02:42:28AM +, David Jones wrote:
> > Maybe allow the RelayCountry check to happen on the msa network or the
> > first relay?
> >
> > Or something like trusted_countries that could provide a limit/boundary
> >
On Fri, Jul 05, 2019 at 02:42:28AM +, David Jones wrote:
> Maybe allow the RelayCountry check to happen on the msa network or the
> first relay?
>
> Or something like trusted_countries that could provide a limit/boundary
> to the trust of trusted_networks?
>
> Compromised accounts often get
On 7/4/19 6:35 PM, Bill Cole wrote:
> On 4 Jul 2019, at 16:59, David Jones wrote:
>
>> It seems like authenticated mail submission should only apply to
>> internal_networks and not extend out to the trusted_networks.
>
> No. See https://wiki.apache.org/spamassassin/DynablockIssues.
>
> In short: if
On 4 Jul 2019, at 16:59, David Jones wrote:
It seems like authenticated mail submission should only apply to
internal_networks and not extend out to the trusted_networks.
No. See https://wiki.apache.org/spamassassin/DynablockIssues.
In short: if you don't trust the authentication of your
tru
my trusted_networks since it will not forge
>> the Received header.
>
> This is nothing to do with ehlo, it hit ALL_TRUSTED because it's
> authenticated mail submission into the trusted network.
>
Thank you for this information.
It seems like authenticated mail submission s
Received header.
This is nothing to do with ehlo, it hit ALL_TRUSTED because it's
authenticated mail submission into the trusted network.
> The 88.233 IP is from Turkey (88.233.47.16.dynamic.ttnet.com.tr) and
> should have triggered a number of rules based on the RelayCountry
> plu
net.com.tr) and
should have triggered a number of rules based on the RelayCountry plugin.
This email should not have hit ALL_TRUSTED and should have done
RelayCountry and ASN lookups on 88.233.47.16.
Received: from mail.lced.net (mail.lced.net [96.4.156.2])
by smtp5i.ena.net (Postfix) wit
>
> its not done automatic
>
> ALL_TRUSTED is not a amavis problem to solve
>
> so keep it here, until solved
slightly resurrecting this, for posterity. i've recently upgraded, amavis to
2.11.0 and spamassassin to 3.4.2. since then, this behavior has stopped and i
On Sun, 11 Nov 2018, John Hardin wrote:
On Sat, 10 Nov 2018, listsb wrote:
what am i misunderstanding?
Is there some possibility that you're stripping external Received headers?
(grasping at straws here)
Heh. Ignore that. I have *got* to learn to catch up *before* replying to
stuff... :)
On Sat, 10 Nov 2018, listsb wrote:
On Nov 10, 2018, at 21.01, John Hardin wrote:
On Sat, 10 Nov 2018, listsb wrote:
i've just noticed that every mail received seems to be hitting the ALL_TRUSTED
test [ALL_TRUSTED=-1], regardless of where the message has come from. i have
the foll
listsb skrev den 2018-11-11 19:20:
thanks, agreed. is continuation of this discussion ok here? or
should i take to the amavis list?
its important that networks ip ranges is equal in all software used
its not done automatic
ALL_TRUSTED is not a amavis problem to solve
so keep it here
>On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote:
>>i've just noticed that every mail received seems to be hitting the
ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come from. i
have the following:
>>
>>>grep -riF 'internal_ne
On Nov 11, 2018, at 13.18, Matus UHLAR - fantomas wrote:
>
>>> On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote:
>>>> i've just noticed that every mail received seems to be hitting the
>>>> ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the
On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote:
i've just noticed that every mail received seems to be hitting the ALL_TRUSTED
test [ALL_TRUSTED=-1], regardless of where the message has come from. i have
the following:
grep -riF 'internal_networks' /etc/spama
> On Nov 11, 2018, at 12.23, Henrik K wrote:
>
> On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote:
>> hi-
>>
>> i've just noticed that every mail received seems to be hitting the
>> ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the
> On Nov 11, 2018, at 12.05, RW wrote:
>
> On Sun, 11 Nov 2018 10:35:18 -0500
> listsb wrote:
>
>>> On Nov 11, 2018, at 09.01, Matus UHLAR - fantomas
>>> wrote:
>>>
>>> On 10.11.18 20:04, listsb wrote:
>>>> i've just notic
On Sun, Nov 11, 2018 at 06:43:27PM +0100, Matus UHLAR - fantomas wrote:
> >On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote:
> >>i've just noticed that every mail received seems to be hitting the
> >>ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the m
Amavisd does not use spamassassin *networks settings
Orignation bug is not spamassassin problem
Benny
On 11. november 2018 18.24.05 Henrik K wrote:
On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote:
hi-
i've just noticed that every mail received seems to be hitting the
ALL_TR
On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote:
i've just noticed that every mail received seems to be hitting the ALL_TRUSTED
test [ALL_TRUSTED=-1], regardless of where the message has come from. i have
the following:
>grep -riF 'internal_networks' /etc/s
On Sat, Nov 10, 2018 at 08:04:42PM -0500, listsb wrote:
> hi-
>
> i've just noticed that every mail received seems to be hitting the
> ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come
> from. i have the following:
>
> >grep -riF 'in
On Sun, 11 Nov 2018 10:35:18 -0500
listsb wrote:
> > On Nov 11, 2018, at 09.01, Matus UHLAR - fantomas
> > wrote:
> >
> > On 10.11.18 20:04, listsb wrote:
> >> i've just noticed that every mail received seems to be hitting the
> >> ALL_TRUSTED
> On Nov 11, 2018, at 09.01, Matus UHLAR - fantomas wrote:
>
> On 10.11.18 20:04, listsb wrote:
>> i've just noticed that every mail received seems to be hitting the
>> ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come
>> from. i have
On 10.11.18 20:04, listsb wrote:
i've just noticed that every mail received seems to be hitting the ALL_TRUSTED
test [ALL_TRUSTED=-1], regardless of where the message has come from. i have
the following:
grep -riF 'internal_networks' /etc/spamassassin/*
/etc/spamas
On Nov 10, 2018, at 21.01, John Hardin wrote:
>
> On Sat, 10 Nov 2018, listsb wrote:
>
>> hi-
>>
>> i've just noticed that every mail received seems to be hitting the
>> ALL_TRUSTED test [ALL_TRUSTED=-1], regardless of where the message has come
>&g
On Sat, 10 Nov 2018, listsb wrote:
hi-
i've just noticed that every mail received seems to be hitting the ALL_TRUSTED
test [ALL_TRUSTED=-1], regardless of where the message has come from. i have
the following:
grep -riF 'internal_networks' /etc/spamassassin/*
/etc/spamas
hi-
i've just noticed that every mail received seems to be hitting the ALL_TRUSTED
test [ALL_TRUSTED=-1], regardless of where the message has come from. i have
the following:
>grep -riF 'internal_networks' /etc/spamassassin/*
/etc/spamassassin/99_local-config.cf
trusted? yes internal? yes msa? no
>
> but I'm not clear how it decides if it should short circuit or not.
> Can anyone clarify?
> X-Spam-Status: No, ... UNPARSEABLE_RELAY
It's because the other received header is not parseable,
UNPARSEABLE_RELAY prevents ALL_TRUSTED from be
From: micah anderson
>I have trusted_networks and internal_networks configured, and have been
>short-circuiting spam processing when messages come from those
>networks.
>I have:
>shortcircuit ALL_TRUSTED on
I would advise against this since you need to do proper outbound fil
nning as the same user that
> > > > runs your Amavisd* and examine the first ~20 line of the debug
> > > > output, which will show you how SA is parsing those Received
> > > > headers as well as what version of Net::DNS you're using.
> > >
> >
isd* and examine the first ~20 line of the debug output,
> > > which will show you how SA is parsing those Received headers as
> > > well as what version of Net::DNS you're using.
> >
> > Good point! Running spamassassin from command line works fine and
> > does not
Am 12.04.2016 um 15:03 schrieb Helmut Schneider:
Amavisd runs chrooted, how can I debug SA while running from amavisd?
why are you running it chrooted?
you know how easy it is to miss important things in the jail or fail
them to update properly - especially in a complex setup?
just make y
On 12 Apr 2016, at 9:03, Helmut Schneider wrote:
Bill Cole wrote:
On 11 Apr 2016, at 10:55, Helmut Schneider wrote:
Hi,
for more than 6 months I'm trying to fix ALL_TRUSTED=-1 without
success.
Did it just start showing up 6 months ago on a previously-working
SpamAssassin installatio
Bill Cole wrote:
> On 11 Apr 2016, at 10:55, Helmut Schneider wrote:
>
> > Hi,
> >
> > for more than 6 months I'm trying to fix ALL_TRUSTED=-1 without
> > success.
>
> Did it just start showing up 6 months ago on a previously-working
> SpamAssassin
On 11 Apr 2016, at 10:55, Helmut Schneider wrote:
Hi,
for more than 6 months I'm trying to fix ALL_TRUSTED=-1 without
success.
Did it just start showing up 6 months ago on a previously-working
SpamAssassin installation, of was SA just set up 6 months ago and has
been broken the whole
On 4/11/2016 12:02 PM, Helmut Schneider wrote:
Bowie Bailey wrote:
On 4/11/2016 10:55 AM, Helmut Schneider wrote:
Hi,
for more than 6 months I'm trying to fix ALL_TRUSTED=-1 without
success.
I have read https://wiki.apache.org/spamassassin/TrustPath and
https://wiki.apache.org/spamass
Martin Gregorie wrote:
> On Mon, 2016-04-11 at 14:55 +, Helmut Schneider wrote:
> >
> > Hi,
> >
> > for more than 6 months I'm trying to fix ALL_TRUSTED=-1 without
> > success.
> >
> > I have read https://wiki.apache.org/spamassassin/Trus
Bowie Bailey wrote:
> On 4/11/2016 10:55 AM, Helmut Schneider wrote:
> > Hi,
> >
> > for more than 6 months I'm trying to fix ALL_TRUSTED=-1 without
> > success.
> >
> > I have read https://wiki.apache.org/spamassassin/TrustPath and
> > htt
On Mon, 2016-04-11 at 14:55 +, Helmut Schneider wrote:
>
> Hi,
>
> for more than 6 months I'm trying to fix ALL_TRUSTED=-1 without
> success.
>
> I have read https://wiki.apache.org/spamassassin/TrustPath and
> https://wiki.apache.org/spamassassin/Fi
On 4/11/2016 10:55 AM, Helmut Schneider wrote:
Hi,
for more than 6 months I'm trying to fix ALL_TRUSTED=-1 without success.
I have read https://wiki.apache.org/spamassassin/TrustPath and
https://wiki.apache.org/spamassassin/FixingAllTrusted carefully, put
trusted_networks 10.0.
Hi,
for more than 6 months I'm trying to fix ALL_TRUSTED=-1 without success.
I have read https://wiki.apache.org/spamassassin/TrustPath and
https://wiki.apache.org/spamassassin/FixingAllTrusted carefully, put
trusted_networks 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
internal_networks 10.0.
am-Level:
X-Spam-Status: No, score=-2.909 tagged_above=- required=5
tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, SPF_PASS=0.001,
T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
...
That same email, subsequently re-injected into the same s
(which is perfectly valid
> according to RFC 5321).
re: UNPARSEABLE_RELAY, done -
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7213
As for ALL_TRUSTED, still need to figure out why it's firing when the relays
are clearly not all in the trust path.
Thanks.
PGNd wrote:
The LHLO/LMTP header still is added at the backend, and
UNPARSEABLE_RELAY still hits. I've not yet determined what the actual
problem with the parsing is.
It's a shortcoming/bug in the SpamAssassin ad-hoc parser.
Please open a Bugzilla ticket and provide a sample of
your Received
Am 19.06.2015 um 16:31 schrieb PGNd:
Fwiw, removing ALL_TRUSTED from the shortcircuiting meta definition certainly
prevents it from triggering the shortcircuit.
However, it still fires -- incorrectly & intermittently, albeit now with a "-1"
score attached.
The LHLO/LMTP h
Fwiw, removing ALL_TRUSTED from the shortcircuiting meta definition certainly
prevents it from triggering the shortcircuit.
However, it still fires -- incorrectly & intermittently, albeit now with a "-1"
score attached.
The LHLO/LMTP header still is added at the backend, and UNP
> Are the 196.28.80.29, 196.28.80.61, and 196.28.66.13 in your
> trusted X.X.X.X/29 ? If they are, then hitting ALL_TRUSTED is expected.
No, the X.X.X.X/29 is a different server -- one of my own, not in a 186. block,
and definitely not in ZA.
> > Jun 18 22:38:19.967 [19747
that gets SHORTCIRCUITED on ALL_TRUSTED
(example below).
I've read through https://wiki.apache.org/spamassassin/TrustPath, and
am missing something; I haven't yet managed to pick out the problem.
My SA config includes the following
internal_networks 127.0.0.0/8 10.2.2.0
Received: from relay09.smp.mweb.co.za (relay09.smp.mweb.co.za
>[196.28.80.29])
>EXT Received: from relay-mc01.smp.mweb.co.za ([196.28.80.61])
>EXT Received: from [196.28.66.13] (helo=MWSJHBMC03)
I recommend disabling the shortcircuit'ing of ALL_TRUSTED and su
gets SHORTCIRCUITED on ALL_TRUSTED (example
below).
I've read through https://wiki.apache.org/spamassassin/TrustPath, and am
missing something; I haven't yet managed to pick out the problem.
My SA config includes the following
/local.cf
internal_networks 127.0.0.
Benny,
> X-Spam-Status: No, score=1.1 tagged_above=-999 required=5
> tests=[ALL_TRUSTED=-0.1, DKIM_ADSP_ALL=1.1, DKIM_SIGNED=0.1,
> DKIM_VALID=-0.1, NO_X_MAILER=0.1] autolearn=no
>
> ALL_TRUSTED does not disable DKIM_ADSP_ALL
Why would an ALL_TRUSTED be disabli
X-Spam-Status: No, score=1.1 tagged_above=-999 required=5
tests=[ALL_TRUSTED=-0.1, DKIM_ADSP_ALL=1.1, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, NO_X_MAILER=0.1] autolearn=no
ALL_TRUSTED does not disable DKIM_ADSP_ALL
priority error ?
--
Benny Pedersen
On Tue, 6 Dec 2011 17:48:10 +0100
Michael Monnerie wrote:
> I get this message:
>
> [21120] dbg: message: X-Envelope-From header found after 1 or more
> Received lines, cannot trust envelope-from
>
> ...
>
> When all headers above X-Envelope-From are from trusted sources, this
> header should al
On Tue, 6 Dec 2011 17:48:10 +0100
Michael Monnerie wrote:
> Why is it ALL_TRUSTED, when my settings are:
Because you put everthing into msa_networks. You shouldn't put MX
servers into msa_networks unless you have no alternative. It causes
subsequent relays to inherit the internal/truste
n to that spam:
[21120] dbg: rules: ran eval rule ALL_TRUSTED ==> got hit (1)
Why is it ALL_TRUSTED, when my settings are:
clear_trusted_networks
clear_internal_networks
clear_msa_networks
trusted_networks 212.69.162.192/28 212.69.164.48/28 195.202.151.128/28
195.202.170.128/29
internal_networks
Casartello, Thomas wrote:
> I'm having an issue with the ALL_TRUSTED rule in SA 3.3.1. I
> recently rebuilt my server running SA, and now for some reason the
> ALL_TRUSTED rule is not triggering when a user sends a message using
> SASL authentication from outside our site. Bef
On Fri, 2010-10-22 at 16:00 -0400, Casartello, Thomas wrote:
> I’m having an issue with the ALL_TRUSTED rule in SA 3.3.1. I recently
> rebuilt my server running SA, and now for some reason the ALL_TRUSTED
> rule is not triggering when a user sends a message using SASL
> authentication
Hello,
I'm having an issue with the ALL_TRUSTED rule in SA 3.3.1. I recently rebuilt
my server running SA, and now for some reason the ALL_TRUSTED rule is not
triggering when a user sends a message using SASL authentication from outside
our site. Before it would work when the sendi
tly upgraded to 3.2.5_4.
>>
>> It's seems now, I never get any hits on the rule ALL_TRUSTED.
>>
>> Previously it seemed like SA was doing some kind of dynamic
>> evaluation which was working well.
>>
>> - Julian
>>
> i
On Tue, Jan 5, 2010 at 5:12 PM, Matt Kettler wrote:
> On 1/5/2010 8:03 PM, Julian Yap wrote:
>
> Previously I was running SpamAssassin-3.1.8_1 on FreeBSD.
>
> I recently upgraded to 3.2.5_4.
>
> It's seems now, I never get any hits on the rule ALL_TRUSTED.
>
>
On 1/5/2010 8:03 PM, Julian Yap wrote:
> Previously I was running SpamAssassin-3.1.8_1 on FreeBSD.
>
> I recently upgraded to 3.2.5_4.
>
> It's seems now, I never get any hits on the rule ALL_TRUSTED.
>
> Previously it seemed like SA was doing some kind of dynamic eval
Previously I was running SpamAssassin-3.1.8_1 on FreeBSD.
I recently upgraded to 3.2.5_4.
It's seems now, I never get any hits on the rule ALL_TRUSTED.
Previously it seemed like SA was doing some kind of dynamic evaluation which
was working well.
- Julian
peter pilsl wrote:
Our mailserver is behind a NAT-firewall (port 25 is passed through to
the internal mailserver) and I ran into the ALL_TRUSTED-problem. I
looked up the FAQ and set
trusted_networks 127.0.0.1 (which actually gives me a warning that
127.0.0.1 is already part of
On 28.03.08 14:26, peter pilsl wrote:
> Our mailserver is behind a NAT-firewall (port 25 is passed through to
> the internal mailserver) and I ran into the ALL_TRUSTED-problem. I
> looked up the FAQ and set
>
> trusted_networks 127.0.0.1 (which actually gives me a warning tha
peter pilsl wrote:
> Our mailserver is behind a NAT-firewall (port 25 is passed through to
> the internal mailserver) and I ran into the ALL_TRUSTED-problem. I
> looked up the FAQ and set
>
> trusted_networks 127.0.0.1 (which actually gives me a warning that
> 127.0.0.1
Our mailserver is behind a NAT-firewall (port 25 is passed through to
the internal mailserver) and I ran into the ALL_TRUSTED-problem. I
looked up the FAQ and set
trusted_networks 127.0.0.1 (which actually gives me a warning that
127.0.0.1 is already part of trusted_networks
On 24/02/2008 10:06 AM, giga328 wrote:
> Client in example is Outlook Express at 89.110.202.24 also in trusted
> networks.
> Relevant configuration lines are:
> trusted_networks 212.62.32.0/19
> trusted_networks 89.110.192.0/18
Not that this is the cause of your problem, but I'm wondering why
89.
r MX and for clients and I
would like to configure SpamAssassin to trust users relayed by
mtaout1.isp.ptt.rs from my example.
Regards,
Giga
--
View this message in context:
http://www.nabble.com/ALL_TRUSTED-and-DOS_OE_TO_MX-tp15659736p15669827.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
On 23.02.08 17:34, giga328 wrote:
> I'm testing SpamAssassin and I'm getting false positives. Both tests
> ALL_TRUSTED and DOS_OE_TO_MX are firing for emails sent by Outlook Express
> for local clients and it seems like I have something wrong in *_networks.
> Here is my setup
am which is not so
relevant because SpamAssasing fires on every email by DOS_OE_TO_MX.
Log line from spamd:
Feb 24 15:11:10 localhost spamd[23664]: spamd: result: . 1 -
ALL_TRUSTED=-1.44,AWL=-0.294,DOS_OE_TO_MX=2.75,HTML_MESSAGE=0.001
scantime=0.8,size=1324,user=(unknown),uid=1783,required_score=5.
On 23/02/2008 8:34 PM, giga328 wrote:
> I'm testing SpamAssassin and I'm getting false positives. Both tests
> ALL_TRUSTED and DOS_OE_TO_MX are firing for emails sent by Outlook Express
> for local clients and it seems like I have something wrong in *_networks.
> Here is my s
I'm testing SpamAssassin and I'm getting false positives. Both tests
ALL_TRUSTED and DOS_OE_TO_MX are firing for emails sent by Outlook Express
for local clients and it seems like I have something wrong in *_networks.
Here is my setup:
All my servers and my clients IP are in truste
Thanks Daryl.
That error is now no more.
Cheers,
AK.
-Original Message-
From: Daryl C. W. O'Shea [mailto:[EMAIL PROTECTED]
Sent: Monday, 18 June 2007 12:59 PM
To: Anthony Kamau
Cc: SpamAssassin Mailing List
Subject: Re: Problems with Received: header checks and ALL_TRUSTED
rule..
Anthony Kamau wrote:
I've checked my logs and noticed the following entry whenever I restart
the spamassassin service:
config: dup unknown type msa_networks, Mail::SpamAssassin::NetSet
Is this something I should be worried about?
As long as you don't have any users calling "clear_msa_networks
ECTED]
Sent: Wednesday, 13 June 2007 5:12 PM
To: Daryl C. W. O'Shea
Cc: SpamAssassin Mailing List
Subject: RE: Problems with Received: header checks and ALL_TRUSTED
rule...
Thanks a ton Daryl.
I've patched my SA 3.1.7 per [1] and it is working as expected.
Cheers,
AK.
C. W. O'Shea [mailto:[EMAIL PROTECTED]
Sent: Thursday, 14 June 2007 11:53 AM
To: Anthony Kamau
Cc: SpamAssassin Mailing List
Subject: Re: Problems with Received: header checks and ALL_TRUSTED
rule...
In any case, spamming people with backscatter in the form of NDRs from
your system is comp
eers,
AK.
-Original Message-
From: Kris Deugau [mailto:[EMAIL PROTECTED]
Sent: Friday, 15 June 2007 12:56 AM
To: users@spamassassin.apache.org
Subject: Re: Problems with Received: header checks and ALL_TRUSTED
rule...
Anthony Kamau wrote:
>
> Any chance you know of a quick and dirty
Anthony Kamau wrote:
Any chance you know of a quick and dirty method to implement sendmail AD
authentication? I did search during build of the sendmail box, but did
not find conclusive instructions to do so - possibly because I was under
immense pressure to get a spam identifier installed.
C
1 - 100 of 359 matches
Mail list logo
