micah anderson wrote:
>
> Hi,
>
> I've got some machines that are running logcheck, they periodically send
> mail to us with reports. Sometimes those mails have some spammy stuff in
> them, because they are mail server logs, or web logs with some spammy
> stuff in them.
>
> I don't want spamass
Am 24.10.2014 um 21:18 schrieb John Hardin:
On Fri, 24 Oct 2014, Reindl Harald wrote:
Am 24.10.2014 um 17:59 schrieb micah anderson:
I've got some machines that are running logcheck, they periodically
send
mail to us with reports. Sometimes those mails have some spammy
stuff in
them, becau
On Fri, 24 Oct 2014, Reindl Harald wrote:
Am 24.10.2014 um 17:59 schrieb micah anderson:
I've got some machines that are running logcheck, they periodically send
mail to us with reports. Sometimes those mails have some spammy stuff in
them, because they are mail server logs, or web logs with
On 10/24/2014 05:59 PM, micah anderson wrote:
Hi,
I've got some machines that are running logcheck, they periodically send
mail to us with reports. Sometimes those mails have some spammy stuff in
them, because they are mail server logs, or web logs with some spammy
stuff in them.
I don't want
Am 24.10.2014 um 17:59 schrieb micah anderson:
I've got some machines that are running logcheck, they periodically send
mail to us with reports. Sometimes those mails have some spammy stuff in
them, because they are mail server logs, or web logs with some spammy
stuff in them.
I don't want spam
Hi,
I've got some machines that are running logcheck, they periodically send
mail to us with reports. Sometimes those mails have some spammy stuff in
them, because they are mail server logs, or web logs with some spammy
stuff in them.
I don't want spamassassin to deal with these messages, I wan
On 8/16/2013 9:43 AM, Martin Gregorie wrote:
If your mail is being routed via your ISP's MTAs you probably need to
add them to trusted_networks too.
internal_networks it is.
On 16.08.13 10:45, Gregg Stock wrote:
I have an MX record that points to our staic IP. So I don't have an
external MTA.
at 09:27 -0700, Gregg Stock wrote:
>> I'm getting some ALL_TRUSTED on spam and wasn't sure what to list in as
>> trusted networks. My mail server has incoming messages port forwarded by
>> iptables. So everything looks like it comes from an internal network.
>> Right n
On Fri, 2013-08-16 at 09:27 -0700, Gregg Stock wrote:
> I'm getting some ALL_TRUSTED on spam and wasn't sure what to list in as
> trusted networks. My mail server has incoming messages port forwarded by
> iptables. So everything looks like it comes from an internal network.
>
I'm getting some ALL_TRUSTED on spam and wasn't sure what to list in as
trusted networks. My mail server has incoming messages port forwarded by
iptables. So everything looks like it comes from an internal network.
Right now, I have our LAN on the trusted networks but not the network
Thanks for the reminder . . .
joe a.
>>> On 2/5/2013 at 1:03 PM, wrote:
> I feel like this comes up often enough, people not having trusted_networks
> or internal_networks set.
>
> Probably for most people it's unnecessary. But if you have some server
> relaying / forwarding mail to your se
I feel like this comes up often enough, people not having trusted_networks
or internal_networks set.
Probably for most people it's unnecessary. But if you have some server
relaying / forwarding mail to your server, and you don't have one of these
set, spamassassin is using the IP address of tha
> *Απο:* Benny Pedersen
> *Προς:* users@spamassassin.apache.org
> *Στάλθηκε:* 4:34 μ.μ. Παρασκευή, 9 Μαρτίου 2012
> *Θεμα:* Re: Trusted Networks and scoring
>
> Den 2012-03-09 09:11, Jari Fredriksson skrev:
>
>> No, SA will scan
I will check next Monday morning, but my feeling is that the @local_domains_acl
is not set.
But according to what is in the NOTE, it is implied that the headers are added
to incoming emails only.
This it not what I want...
P.
Den 2012-03-09 18:33, Peter Tselios skrev:
What do you mean to check at the local_domain? Should it have a
specific value?
headers would only be added to local_domains
# NOTE:
# For backwards compatibility the variable names @local_domains (old)
and
# @local_domains_acl (new) are synon
> check local_domain in amavisd.conf
What do you mean to check at the local_domain? Should it have a specific value?
Den 2012-03-09 17:59, Peter Tselios skrev:
Any ideas?
check local_domain in amavisd.conf
(PS: Sorry to write on the top, but Yahoo! is not very helpful on
that
road to hell is made with bad excuses
Any ideas?
(PS: Sorry to write on the top, but Yahoo! is not very helpful on that :)
Απο: Benny Pedersen
Προς: users@spamassassin.apache.org
Στάλθηκε: 4:34 μ.μ. Παρασκευή, 9 Μαρτίου 2012
Θεμα: Re: Trusted Networks and scoring
Den 2012-03-09 09:11, Jari Fredr
Den 2012-03-09 09:11, Jari Fredriksson skrev:
No, SA will scan messages even if they originate from
trusted_networks,
and X-Spam headers will be added.
most sites bypass scanning of there own mails since its just ham
(permit_mynetworks) in postfix, my point is why not learn ham in bayes ?
Den 2012-03-09 08:50, Peter Tselios skrev:
I noticed that for users originating from my networks, the X-Spam
headers are not added to the messages.
how do you use spamassassin ?, i still not get that ball to see all
here
9.3.2012 9:50, Peter Tselios kirjoitti:
> Good morning,
> I noticed that for users originating from my networks, the X-Spam
> headers are not added to the messages. Is that due to the
> "trusted_networks" settings? If so, does that mean that spamassassin
> does not check them?
> P.
No, SA will sca
Good morning,
I noticed that for users originating from my networks, the X-Spam headers are
not added to the messages. Is that due to the "trusted_networks" settings? If
so, does that mean that spamassassin does not check them?
P.
On Fri, 05 Jun 2009 10:24:31 -0400
Micah Anderson wrote:
If I understand things properly, because I've got these
> setup in my trusted_networks, then these previous hops will be
> checked in RBLs, so the spam is more detectable.
That doesn't really help. If you think about it, tests that run on
I get a significant amount of spam that comes through mailing lists that
I am legitimately subscribed to, either they are the administration
emails asking me if I want to approve the "email" or not, or they are
messages that make it through the list.
These messages are either hitting ALL_TRUSTED,
On 6/26/2008 6:51 AM, Henrik K wrote:
Extending trusted_networks beyond internal offers another way to whitelist
(ALL_TRUSTED) and reduces lookups (and possible RBL FPs with that). I'm
currently converting DNSWL data to trusted_network entries, which works
great (needs patches from bugs #5931 #58
On Wed, Jun 25, 2008 at 08:54:20PM -0400, Matt Kettler wrote:
> Benny Pedersen wrote:
>> On Fredag, 20/6 2008, 10:04, Henrik K wrote:
>>
>>> On Fri, Jun 20, 2008 at 12:12:45AM -0400, Matt Kettler wrote:
>>>
That is correct, SPF checks are applied to the first untrusted host.
Kshatriya wrote:
Hey,
I've just read 127.* is now always trusted in the new release of
SpamAssassin.
However, i have some mailinglists which are being handled with SmartList
(which runs on top of procmail). So, when a spammail hits this list, it
gets marked as spam (hopefully), but then it
Hey,
I've just read 127.* is now always trusted in the new release of
SpamAssassin.
However, i have some mailinglists which are being handled with SmartList
(which runs on top of procmail). So, when a spammail hits this list, it
gets marked as spam (hopefully), but then it will be processed
On 2/27/2007 12:45 PM, Ben Wylie wrote:
Daryl C. W. O'Shea wrote:
Assuming you've got your trusted_networks (and possibly
internal_networks) setup, you just need to add
"always_trust_envelope_sender 1" to your local.cf.
Thanks for the help.
It now gives me the error
[3952] dbg: spf: cannot
Daryl C. W. O'Shea wrote:
Assuming you've got your trusted_networks (and possibly
internal_networks) setup, you just need to add
"always_trust_envelope_sender 1" to your local.cf.
Thanks for the help.
It now gives me the error
[3952] dbg: spf: cannot get Envelope-From, cannot use SPF
[3952] db
Ben Wylie wrote:
but then refuses to do any more, as it claims not to be able to trust
the X-Envelope-From header because it has been through my AV gateway:
[2408] dbg: spf: relayed through one or more trusted relays, cannot use
header-based Envelope-From, skipping
Similarly:
[2408] dbg: spf
t SPF checks on the senders as well as be able to use
> SPF Whitelist From.
perldoc Mail::SpamAssassin::Conf there you find envelope
for the internal networks / trusted networks, you should have internal cower
the wan ip of your server and local ips aswell
for trusted networks add forwardin
All of my emails pass through an antivirus gateway which is the same
server as the mailserver and appears like this in the headers:
Received: from [127.0.0.1] by arkbb.co.uk with SMTP (HELO server.)
(ArGoSoft Mail Server Pro for WinNT/2000/XP, Version 1.8 (1.8.8.9));
Mon, 26 Feb 2007 15:41:0
Ross Boylan wrote:
> On Thu, 2006-06-29 at 19:52 -0400, Matt Kettler wrote:
>
>> Ross Boylan wrote:
>>
>>> On Thu, 2006-06-29 at 00:30 -0400, Matt Kettler wrote:
>>>
>>>
>>>
No, internal must never receive mail directly from a dialup node. SA
applies DUL RBLs and other s
On Thu, 2006-06-29 at 19:52 -0400, Matt Kettler wrote:
> Ross Boylan wrote:
> > On Thu, 2006-06-29 at 00:30 -0400, Matt Kettler wrote:
> >
> >
> >> No, internal must never receive mail directly from a dialup node. SA
> >> applies DUL RBLs and other such tests against hosts delivering mail to
> >
Ross Boylan wrote:
> On Thu, 2006-06-29 at 00:30 -0400, Matt Kettler wrote:
>
>
>> No, internal must never receive mail directly from a dialup node. SA
>> applies DUL RBLs and other such tests against hosts delivering mail to
>> internal hosts.
>>
> I thought internal_hosts never get mail f
On Thu, 2006-06-29 at 00:30 -0400, Matt Kettler wrote:
> No, internal must never receive mail directly from a dialup node. SA
> applies DUL RBLs and other such tests against hosts delivering mail to
> internal hosts.
I thought internal_hosts never get mail from DUL RBLs. So why would SA
check if
> Ok, well that is resolvable. What is actually meant
> to be included as "internal" and what is the difference
> between that and trusted networks? If something is
> trusted then it can be treated as internal, or can't it?
The "simple" rule is internal_netwo
Ben Wylie wrote:
>>> As i understand it, in trusted networks you want
>>> to have any ip or ip range that you trust to be
>>> reporting correctly the details of the server from
>>> which it received the email.
>>>
>> Yes, howev
>> As i understand it, in trusted networks you want
>> to have any ip or ip range that you trust to be
>> reporting correctly the details of the server from
>> which it received the email.
>
> Yes, however there's another stipulation.. By default,
> if undec
Ben Wylie wrote:
> As i understand it, in trusted networks you want to have any ip or ip range
> that you trust to be reporting correctly the details of the server from which
> it received the email.
>
> If this is the case, presumably it is good to have the main service provide
As i understand it, in trusted networks you want to have any ip or ip range
that you trust to be reporting correctly the details of the server from which
it received the email.
If this is the case, presumably it is good to have the main service provider
servers in this list.
So if i know that
p on their names. Use "host" or "dig" to perform
the lookup on your SA box.
i.e: host xanadu.evi-inc.com
xanadu.evi-inc.com has address 192.168.xx.yy
3) make a trusted networks that encompasses all of those IPs, as well as
127.0.0.1. Being a little over-broad is OK, as long a
Gestern (24.03.2006/22:43 Uhr) schrieb Matt Kettler,
> Bowie Bailey wrote:
>> Craig McLean wrote:
>>> Bowie Bailey wrote:
>>> [snip]
>>>
You should define all of the IP addresses of your mailserver.
I don`t know yet how I must determine the trusted network. :(
192.168.1/24 127/8 is clear for
Bowie Bailey wrote:
> Craig McLean wrote:
>> Bowie Bailey wrote:
>> [snip]
>>
>>> You should define all of the IP addresses of your mailserver.
>>>
>>> trusted_networks 192.168.128.4
>>> trusted_networks 69.27.243.222
>> (I'm not the OP...)
>>
>> Do those addresses need to be CIDR? Or will SA take
Daryl C. W. O'Shea wrote:
> When automatically set, yes. When you manually define your
> trusted/internal networks, no -- you really get to define them.
OK, that makes sense.
--
Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Softw
Craig McLean wrote:
> Bowie Bailey wrote:
> [snip]
>
> >
> > You should define all of the IP addresses of your mailserver.
> >
> > trusted_networks 192.168.128.4
> > trusted_networks 69.27.243.222
>
> (I'm not the OP...)
>
> Do those addresses need to be CIDR? Or will SA take straight-out IP?
[EMAIL PROTECTED] wrote:
Daryl C. W. O'Shea wrote:
You might as well through in trusted_networks 127.0.0.1
... that's not hardcoded?
When automatically set, yes. When you manually define your
trusted/internal networks, no -- you really get to define them.
Daryl C. W. O'Shea wrote:
> You might as well through in trusted_networks 127.0.0.1
... that's not hardcoded?
--
Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902
Hispanic Business Inc./HireDiversity.com Software Engineer
Jim Maul wrote:
Bowie Bailey wrote:
My question is, with this setup, what trusted_networks should i have
defined?
You should define all of the IP addresses of your mailserver.
trusted_networks 192.168.128.4
trusted_networks 69.27.243.222
I see that 167.206.112.76 (mx1.lightpath.net) also ac
Bowie Bailey wrote:
My question is, with this setup, what trusted_networks should i have
defined?
You should define all of the IP addresses of your mailserver.
trusted_networks 192.168.128.4
trusted_networks 69.27.243.222
I see that 167.206.112.76 (mx1.lightpath.net) also accepts mail for yo
Jim Maul wrote:
> I believe i am having an issue with my trusted networks and am hoping
> someone can help me figure out what to do. I currently do not have
> any defined and am running a nat'ed server which from what i read will
> pretty much always have problems with trust
I believe i am having an issue with my trusted networks and am hoping
someone can help me figure out what to do. I currently do not have any
defined and am running a nat'ed server which from what i read will
pretty much always have problems with trusted networks. The thing is,
i
Liam-PrintingAutomation wrote:
> Also, when using IP's, can you use a full IP, or do you have to leave
> the last octet off (after the period) like in the example?
Yes, you can do a full IP.. In fact, in some old versions, leaving the end off
doesn't work right, so I'd recommend always specifying
Liam-PrintingAutomation wrote:
> These are some stupid questions, but I can't find answers for them doing
> a Google search. I can't seem to find any example local.cf's that have
> more than one trusted networks.
What about man Mail::SpamAssassin::Conf under &quo
These are some stupid questions, but I can't find
answers for them doing a Google search. I can't seem to find any
example local.cf's that have more than one trusted networks.
In the default local.cf, there's this section:
# Set which networks or hosts are considered &#
At 12:04 PM 3/4/2005, Matthew Newton wrote:
OK, thanks. I still have problems exactly understanding the difference
between trusted_networks and internal_networks is, though. My
understanding is that trusted_networks is our entire ip address range,
all hosts (143.210.0.0/16), and internal_networks i
On Fri, Mar 04, 2005 at 12:23:10PM -0500, Daryl C. W. O'Shea wrote:
> Matthew Newton wrote:
> >OK, thanks. I still have problems exactly understanding the difference
> >between trusted_networks and internal_networks is, though. My
> >understanding is that trusted_networks is our entire ip address r
Sandy S wrote:
This looks like another "reserved IP" issue, as discussed in this thread:
http://thread.gmane.org/gmane.mail.spam.spamassassin.general/62078
If you look at the original received header, it shows an IP address of
71.8.202.198, which spamassassin sees as a reserved, and thus trusted, I
Matthew Newton wrote:
OK, thanks. I still have problems exactly understanding the difference
between trusted_networks and internal_networks is, though. My
understanding is that trusted_networks is our entire ip address range,
all hosts (143.210.0.0/16), and internal_networks is mail servers that
we
On Fri, Mar 04, 2005 at 11:07:46AM -0600, Sandy S wrote:
> This looks like another "reserved IP" issue, as discussed in this thread:
> http://thread.gmane.org/gmane.mail.spam.spamassassin.general/62078
>
> If you look at the original received header, it shows an IP address of
> 71.8.202.198, which
- Original Message -
From: "Daryl C. W. O'Shea" <[EMAIL PROTECTED]>
To: "Matt Kettler" <[EMAIL PROTECTED]>
Cc: "Matthew Newton" <[EMAIL PROTECTED]>;
Sent: Friday, March 04, 2005 10:57 AM
Subject: Re: ALL_TRUSTED rule hit, but ha
On Fri, Mar 04, 2005 at 11:57:37AM -0500, Daryl C. W. O'Shea wrote:
> Matt Kettler wrote:
> >At 10:23 AM 3/4/2005, Matthew Newton wrote:
> >
> >>Just had a spam arrive that was given a -3.3 score for "ALL_TRUSTED".
> >>Funny thing is that my local.cf contains the following:
> >>
> >> # we trust ou
Matt Kettler wrote:
At 10:23 AM 3/4/2005, Matthew Newton wrote:
Just had a spam arrive that was given a -3.3 score for "ALL_TRUSTED".
Funny thing is that my local.cf contains the following:
# we trust our local network
# removed: sa never used for internal originating spam.
clear_trusted_netw
At 10:23 AM 3/4/2005, Matthew Newton wrote:
Just had a spam arrive that was given a -3.3 score for "ALL_TRUSTED".
Funny thing is that my local.cf contains the following:
# we trust our local network
# removed: sa never used for internal originating spam.
clear_trusted_networks
#trusted_netw
Hi,
Sorry if this has been mentioned before. I seem to remember that it
might have been, but I can't find it.
Just had a spam arrive that was given a -3.3 score for "ALL_TRUSTED".
Funny thing is that my local.cf contains the following:
# we trust our local network
# removed: sa never used fo
At 03:42 PM 9/29/2004, Shane Metler wrote:
I believe the problem to be that the 'trusted networks' is considered any
IP on our same network, not our specific customer SMTP servers.
I guess my real question is, How can I prevent this case? This message
was relayed through an off
Title: Message
Hi
there,
I think I understand
the use of trusted networks, and the firsttrusted option for RBL lookups, but
I'm getting some unexpected behavior here. I'm guessing it is caused by SA
inferring additional trusted networks?
My goal: To
identify and heavily
68 matches
Mail list logo
