:
Oct 14 09:47:45.091 [1486800] dbg: DMARC: using Mail::DMARC::PurePerl
for DMARC checks
Oct 14 09:47:45.091 [1486800] dbg: DMARC: no external relay found,
skipping DMARC check
What is "external relay"?
A mail source which is not under the control of the entity managing the
SpamAssassi
: DMARC: no external relay found, skipping
DMARC check
What is "external relay"?
How to enable DMARC check?
Regards,
--
Gregory COLPART
Hi,
> this is question for policyd-spf and its configuration.
>
> >The problem here is that something appears to be preventing my
> >welcomelist_auth entries from working properly, but I don't really
> >understand how.
>
> I guess it's the whitelist in policyd-spf.
Is it possible that it's some
>https://pastebin.com/TvTx6KzY
X-Comment: SPF skipped for whitelisted relay domain -
client-ip=13.110.6.221; helo=smtp14-ph2-sp4.mta.salesforce.com;
envelope-from=re...@support.meridianlink.com; receiver=
X-Greylist: whitelisted by SQLgrey-1.8.0
isn't it possible that it's
Hi,
> >https://pastebin.com/TvTx6KzY
>
> X-Comment: SPF skipped for whitelisted relay domain -
> client-ip=13.110.6.221; helo=smtp14-ph2-sp4.mta.salesforce.com;
> envelope-from=re...@support.meridianlink.com; receiver=
> X-Greylist: whitelisted by SQLgrey-1.8.0
>
>
>I'm trying to understand why some domains are not whitelisted even
>though they pass SPF and are in my local welcomelist_auth entries. I'm
>using policyd-spf with postfix, and it appears to be adding the
>following header:
>
>X-Comment: SPF skipped for whitelist
> >I'm trying to understand why some domains are not whitelisted even
> >though they pass SPF and are in my local welcomelist_auth entries. I'm
> >using policyd-spf with postfix, and it appears to be adding the
> >following header:
> >
> >X-Com
> we wait for spamassassin 4.0.0 :=)
>
> 4.0.0 is in pre-release now and in production for a few of us. Start
stress testing it now so we can shake out the bugs and get it out the door!
Regards,
KAM
e wait for spamassassin 4.0.0 :=)
amavisd does not know anything about spf btw
X-Comment: SPF skipped for whitelisted relay domain -
client-ip=13.110.6.221; helo=smtp14-ph2-sp4.mta.salesforce.com [1];
envelope-from=re...@support.meridianlink.com; receiver=
mail::spf does not know this header, i
On 05.05.22 18:01, Alex wrote:
I'm trying to understand why some domains are not whitelisted even
though they pass SPF and are in my local welcomelist_auth entries. I'm
using policyd-spf with postfix, and it appears to be adding the
following header:
X-Comment: SPF skipped for whiteli
; Hi,
>
> I'm trying to understand why some domains are not whitelisted even
> though they pass SPF and are in my local welcomelist_auth entries. I'm
> using policyd-spf with postfix, and it appears to be adding the
> following header:
>
> X-Comment: SPF skippe
Hi,
I'm trying to understand why some domains are not whitelisted even
though they pass SPF and are in my local welcomelist_auth entries. I'm
using policyd-spf with postfix, and it appears to be adding the
following header:
X-Comment: SPF skipped for whitelisted relay domain -
Rupert Gallagher skrev den 2020-03-05 00:27:
Fails with travelling clients.
my custommers want vacation without stress :=)
On 04 Mar 2020, at 16:27, Rupert Gallagher wrote:
> Fails with travelling clients.
Depends. I block several countries from accessing my mail server. If someone
travels to one of those countries, they can use webmail to access their mail.
There are always options.
However, most people simply us
Fails with travelling clients.
Original Message
On Mar 3, 2020, 16:49, Benny Pedersen wrote:
> Marc Roos skrev den 2020-03-03 16:15:
>> Use ipset, hardly causing any latency using 50k entries.
>
> i dont need to block 50k entries, but only whitelist few accepted client
> ips, wh
On 4 Mar 2020, at 14:43, RW wrote:
On Tue, 03 Mar 2020 16:05:31 -0800
Ted Mittelstaedt wrote:
2FA isn't going to help unless 2FA could be applied to the SMTP Auth
port.
Sometime 2FA on webmail is combined with separate autogenerated
passwords for pop/imap/submission.
A.k.a. "application p
On Tue, 03 Mar 2020 16:05:31 -0800
Ted Mittelstaedt wrote:
> 2FA isn't going to help unless 2FA could be applied to the SMTP Auth
> port.
Sometime 2FA on webmail is combined with separate autogenerated
passwords for pop/imap/submission.
2020 10:26 AM, "Ted Mittelstaedt" wrote:
> I know this is probably off topic but I'm getting desperate enough to ask.
>
> I run a commercial mailserver that regularly seems to have spammers relay
> mail through it that have
> obtained stolen credentials for a
On 3/3/2020 5:53 AM, Riccardo Alfieri wrote:
On 03/03/20 08:54, Benny Pedersen wrote:
Ted Mittelstaedt skrev den 2020-03-03 08:26:
What do other people do for this problem?
Hi Ted,
What I can suggest you is to look at our DQS product
(https://www.spamhaustech.com/dqs/), that even in it
Well for example of the trouble RBLS cause see this one for your own number:
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no
trust
[212.26.193.44 listed in list.dnswl.org]
>and then immediately forget it, wh
On 3/3/20 3:40 AM, Marc Roos wrote:
No problem I would say, it is good exchange thoughts and idea's
Agreed.
Strange your webmail should be on https then it is difficult to catch
passwords. I do not have this at al, that peoples passwords get stolen.
Hardly ever. So maybe somewhere something
On 3 Mar 2020, at 2:26, Ted Mittelstaedt wrote:
I know this is probably off topic but I'm getting desperate enough to
ask.
I run a commercial mailserver that regularly seems to have spammers
relay mail through it that have obtained stolen credentials for a
user. Many years ago I st
Marc Roos skrev den 2020-03-03 16:15:
Use ipset, hardly causing any latency using 50k entries.
i dont need to block 50k entries, but only whitelist few accepted client
ips, where i resolve asn and open this specifik asn to have access, if
there is abuse it will be removed so its again is bloc
Use ipset, hardly causing any latency using 50k entries.
-Original Message-
From: Benny Pedersen [mailto:m...@junc.eu]
Sent: 03 March 2020 15:39
To: users@spamassassin.apache.org
Subject: Re: Question on early detection for relay spam
Riccardo Alfieri skrev den 2020-03-03 14:53
Riccardo Alfieri skrev den 2020-03-03 14:53:
# abuse port 21 begin
51.178.0.0/16 as16276 #OVH, FR
80.82.77.0/24 as202425 #INT-NETWORK, SC
104.206.128.0/22 as62904 #EONIX-COMMUNICATIONS-ASBLOCK-62904, US
# abuse port 21 end
# all ips begin
51.178.78.154
80.82.77.240
104.206.128.54
# all ips end
#
Riccardo Alfieri skrev den 2020-03-03 14:53:
sasl_username - number of different ips observed in the latest 24h.
i have limited so that i only allow sasl auth from trusted custommers
ips, all else is firewalled witd default policy of drop, and clients ips
is so just still logged if ports is
On 03/03/20 08:54, Benny Pedersen wrote:
Ted Mittelstaedt skrev den 2020-03-03 08:26:
What do other people do for this problem?
Hi Ted,
What I can suggest you is to look at our DQS product
(https://www.spamhaustech.com/dqs/), that even in it's free subscription
model includes AuthBL, a l
>I know this is probably off topic but I'm getting desperate enough to
ask.
No problem I would say, it is good exchange thoughts and idea's
>I run a commercial mailserver that regularly seems to have spammers
>relay mail through it that have obtained stolen cred
Ted Mittelstaedt skrev den 2020-03-03 08:26:
What do other people do for this problem?
https://www.abusix.com/abusix-mail-intelligence
what more do you want to do ?
my own servers reject all clients not in danish ip space unless its sasl
authed
strong leaked passwords does not help much
I know this is probably off topic but I'm getting desperate enough to ask.
I run a commercial mailserver that regularly seems to have spammers
relay mail through it that have obtained stolen credentials for a user.
Many years ago I stopped allowing users to change passwords on it and
I
On Wed, 28 Nov 2018 at 10:36, Brent Clark wrote:
> Sorry if I can just add, maybe the documentation can be updated?
>
> https://wiki.apache.org/spamassassin/RelayCountryPlugin
I think the documentation is fine, the example with the hat/circumflex has
describe text 'First untr
llback to the 'fast' version ...")
It looks like KR is getting found but if you look at the pastebin
below,
it does not display RELAYCOUNTRY
https://pastebin.com/sh8S10ph
You use a hat ^ so that only the first (or ?last) relay server's
country is matche
://pastebin.com/sh8S10ph
You use a hat ^ so that only the first (or ?last) relay server's country
is matched. Maybe this is the problem? Try using:
header RELAYCOUNTRY_BAD X-Relay-Countries =~ /(CN|RU|SU|IN|BR|UA|KR)/
I use a similar header match string (but with GeoIP2 database, not the
old GeoIP) and it seems to work fine.
ast' version ...")
>
> It looks like KR is getting found but if you look at the pastebin below,
> it does not display RELAYCOUNTRY
>
> https://pastebin.com/sh8S10ph
You use a hat ^ so that only the first (or ?last) relay server's country is
matched. Maybe this is
:RelayCountry', is not picking up Korea.
>>>
>>> https://pastebin.com/i45KsgVk
>> Try running it through
>> spamassassin -D metadata 1>/dev/null
>> and look for debug about what database type is being used. I've found
>> that the plugin will
that the plugin will fallback to the 'fast' version if anything is
wrong and it only shows up in detailed debug.
header RELAYCOUNTRY_BAD X-Relay-Countries
=~ /^(CN|RU|SU|IN|BR|UA|KR)/ describe RELAYCOUNTRY_BAD Relayed
through foreign countries scoreRELAYCOUNTRY_BAD 1.0
add_header all
t through
spamassassin -D metadata 1>/dev/null
and look for debug about what database type is being used. I've found
that the plugin will fallback to the 'fast' version if anything is
wrong and it only shows up in detailed debug.
>
> header RELAYCOUNTRY_BAD X-Rel
On 27.11.18 12:51, Brent Clark wrote:
I have the following spam email, and I picked up that the plugin
'Mail::SpamAssassin::Plugin::RelayCountry', is not picking up Korea.
https://pastebin.com/i45KsgVk
header RELAYCOUNTRY_BAD X-Relay-Countries =~ /^(CN|RU|SU|IN|BR|UA|KR)
Good day Guys
I have the following spam email, and I picked up that the plugin
'Mail::SpamAssassin::Plugin::RelayCountry', is not picking up Korea.
https://pastebin.com/i45KsgVk
header RELAYCOUNTRY_BAD X-Relay-Countries =~ /^(CN|RU|SU|IN|BR|UA|KR)/
describe RELAYCOUNTRY_BAD Relay
On Tue, 14 Nov 2017 12:23:46 -0800
Ian Zimmerman wrote:
> ~$ rblcheck 81.17.24.158
...
> 81.17.24.158 listed by xbl.spamhaus.org
It's a shared VPN address, so I'm not surprised.
~$ rblcheck 81.17.24.158
81.17.24.158 not listed by sbl.spamhaus.org
81.17.24.158 listed by xbl.spamhaus.org
81.17.24.158 not listed by pbl.spamhaus.org
81.17.24.158 not listed by bl.spamcop.net
81.17.24.158 not listed by psbl.surriel.com
81.17.24.158 not listed by dul.dnsbl.sorbs.net
[I wanted to
>On 11.11.17 20:06, Sean Greenslade wrote:
>>SPF checks the final server that transmits the mail. If you are using
>a relay server, that server will need to be in the SPF records.
>
>no. Only outgoing mail servers really need to be in SPF records.
Sorry, I misread the original m
On November 11, 2017 5:31:08 PM PST, Stephan Herker wrote:
I'm running spam assassin default configuration which checks spf
records. In my case I received an email and it checked if the last
relay was a valid sender for SPF. The last relay was a server I have
in
the cloud, so it faile
On Sat, 11 Nov 2017 17:31:08 -0800
Stephan Herker wrote:
> I'm running spam assassin default configuration which checks spf
> records. In my case I received an email and it checked if the last
> relay was a valid sender for SPF. The last relay was a server I have
> in
On 11/11/2017 07:31 PM, Stephan Herker wrote:
I'm running spam assassin default configuration which checks spf
records. In my case I received an email and it checked if the last
relay was a valid sender for SPF. The last relay was a server I have in
the cloud, so it failed SPF even t
On November 11, 2017 5:31:08 PM PST, Stephan Herker wrote:
>I'm running spam assassin default configuration which checks spf
>records. In my case I received an email and it checked if the last
>relay was a valid sender for SPF. The last relay was a server I have
>in
>the
I'm running spam assassin default configuration which checks spf
records. In my case I received an email and it checked if the last
relay was a valid sender for SPF. The last relay was a server I have in
the cloud, so it failed SPF even though original sending server is on
senders SPF r
On Tue, 21 Feb 2017 20:47:06 -0500
David Mehler wrote:
> Hello,
>
> I'm using spamassassin 3.4.1 and trying to tighten up my antispam
> measures. I've enabled the relay country plugin which also has it's
> supporting module of Geo-IP. This is on a FreeBSD system.
Y
Hello,
I'm using spamassassin 3.4.1 and trying to tighten up my antispam
measures. I've enabled the relay country plugin which also has it's
supporting module of Geo-IP. This is on a FreeBSD system.
I am trying to have country data in my message headers. I've added in loca
ike this:
Received: by 10.28.48.15 with SMTP id w15csp2319529wmw;
Tue, 22 Nov 2016 11:10:36 -0800 (PST)
because they don't affect anything. For a received header to count as
unparseable it has to have a "from".
> > and debug mode does not showany message about unparsea
ering...
I'm surprised that it didn't trigger UNPARSEABLE_RELAY, but it is hard
to know why based on one isolated header.
and debug mode does not showany message about unparseable lines. It
seems just ignored, so the relay remains unchecked in RBLS.
As it should. Untrusted relays are unt
is ignored. SA doesn't even try to parse a relay that starts with
"by". It only logs a relay as unparseable if it fails to parse a
relay that might be useful.
This header does contain an IP address, but it's part of what the
header is claiming to be a protocol name.
> so t
message about unparseable lines. It seems just ignored, so the relay
remains unchecked in RBLS.
-Pedro.
Received.pm
module so the relay 158.69.130.12 is never checked
is this normal?
Yes. Why would anyone want SA to attempt to parse an intentionally
deceptive Received header?
Unadulterated Postfix does not now generate (and never has generated)
Received headers like that. The queue id is
Hi,
i have spam emails with a Received line like this:
Received: by 9-30-239-23.uocdn.net (Postfix) with ESMTPSA id 693A0C56B with
(unknown [158.69.130.12]) ; Sun, 20 Nov 2016 21:06:55 -0300
there is no parsing perl code for lines like this in Received.pm module so the
relay 158.69.130.12 is
intended' seems to be a
little long-winded).
Once again, thanks to all.
--
View this message in context:
http://spamassassin.1065346.n5.nabble.com/Advice-why-one-relay-evaluated-and-not-the-other-tp121145p121232.html
Sent from the SpamAssassin - Users mailing list archive at Nabble.com.
, reading it again: it says
> /
> //"trusted_networks IPaddress[/masklen] ... (default: none)//
> //
> //What networks or hosts are 'trusted' in your setup. Trusted in
> this case means that relay hosts on these networks are considered
> to not be potentially operated by spammers, o
jimimaseye wrote on 10/06/16 1:50 AM:
> CONCLUSION: it was working as the book says (even though the book is not
> clear WHY the book says what it says).
It's been a very long while since I worked with this code and I have to kind
of twist my mind up funny to keep it in my head all at once, but t
hat networks or hosts are 'trusted' in your setup. Trusted in
this case means that relay hosts on these networks are considered to
not be potentially operated by spammers, open relays, or open proxies.//
//MXes for your domain(s) and internal relays should also be
specified using the
On Thu, 9 Jun 2016 02:54:34 -0700 (MST)
jimimaseye wrote:
> FEEDBACK for all who have contributed:
>
> I have a result.
>
> It seems that the 'internal_networks' is only adhered to *in the
> absence* of a 'trusted_networks' entry. If I remove the
> 'trusted_networks', and simply leave:
>
> i
as "trusted" and bypassed with the "shortcircuit ALL_TRUSTED" option set, as
shown above). Only without a 'trusted' entry will an 'internal' entry get
applied.
I think we have all learned something there.
Thanks to all.
--
View this message in
Yes it is but it all still works just as the linux version does. So is
irrelevant actually (the only difference being its easier to install and
setup on windows.
--
View this message in context:
http://spamassassin.1065346.n5.nabble.com/Advice-why-one-relay-evaluated-and-not-the-other
On Wed, 8 Jun 2016 12:49:03 -0700 (MST)
jimimaseye wrote:
> On 08/06/2016 21:26, David B Funk [via SpamAssassin] wrote:
> > Try running SA with the '--debug' option to see the explicit list of
> > config files that it is reading. Make sure that it's reading yours
> > and look at the ones that com
> Be sure the user/environment that you test in is the same that is used
> during
> the processing of messages.
>
> Silly question, is some meta-framework involved in your system (EG
> amavis,
> etc..)
>
no, nothing.
--
View this message in context:
http://spamassass
On Wed, 8 Jun 2016, jimimaseye wrote:
On 08/06/2016 16:05, Matus UHLAR - fantomas [via SpamAssassin] wrote:
note that if a server acts as your MX, it should be listed in
internal_networks, no matter if other company manages it.
That applies for backup MX servers for your dom
ly to this email, your message will be added to the
> discussion below:
> http://spamassassin.1065346.n5.nabble.com/Advice-why-one-relay-evaluated-and-not-the-other-tp121145p121189.html
>
>
> To unsubscribe from Advice: why one relay evaluated and not the other,
> click he
On Wed, 08 Jun 2016 13:49:17 +0100, jimimaseye
wrote:
Regarding the range: the range belongs to our mail host provider who
receive the emails then pass them amongst their own servers (doing their
own teats no doubt). Plus they dont have just the one address - an
incoming emial can land at an
On Wed, 08 Jun 2016 13:59:26 +0100
Kevin Golding wrote:
> On Wed, 08 Jun 2016 13:49:17 +0100, jimimaseye
> wrote:
>
> > Regarding the range: the range belongs to our mail host provider
> > who receive the emails then pass them amongst their own servers
> > (doing their own teats no doubt). P
> > Did you restart spamd?
> >
>
> Effectively yes (but no not really). I am using commandline scanner
> whilst doing the tests so the LOCAL.CF is being loaded each time I run
> the test. When it is all working then I will restart my spamd daemon to
> take effect for all incoming mail. P
he next hop and do a Spamhaus
test on [2.25.50.35] just as it was tested and found to be on Spamhaus
by my MTA.
Maybe its my inexperience/novice status. Is it because it is seen as
being the first/sending client? (Suppose so). And therefore the only
'relay' in the chain is the 2nd o
t my spamd daemon to
take effect for all incoming mail. Proof that its working: when I
added the "add_header all Relays-Untrusted" entries (at the same time as
the internal_network entry) they immediately appeared in the spam report.
--
View this message in context:
http://spamassas
On Wed, 08 Jun 2016 13:49:17 +0100, jimimaseye
wrote:
Regarding the range: the range belongs to our mail host provider who
receive the emails then pass them amongst their own servers (doing their
own teats no doubt). Plus they dont have just the one address - an
incoming emial can land at a
On Wed, 8 Jun 2016 05:07:14 -0700 (MST)
jimimaseye wrote:
> * internal_networks 195.26.90.*
Try to avoid using any mark-up (assuming that's what the "*"s are), it
can be very confusing.
> X-Mailer: Apple Mail (2.1085)
> X-hMailServer-Spam: YES
> X-hMailServer-Reason-1: Rejected by Spamhaus. -
RBL: HostKarma: relay in white list
(first pass)
* [195.26.90.72 listed in hostkarma.junkemailfilter.net]
* -0.0 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2)
* [195.26.90.72 listed in wl.mailspike.co]
* 0.0 HTML_MESSAGE BODY: HTML included in message
* -1.0
On Wed, 08 Jun 2016 13:07:14 +0100, jimimaseye
wrote:
I did try adding the "internal_networks 195.26.90. " option to my
LOCAL.CF
before, and in fact I have just tried it again based on your advice, but
it
doesnt make any difference. Here are the headers with
* internal_networks 195.26.
-Untrusted _RELAYSUNTRUSTED_
> add_header all Relays-External _RELAYSEXTERNAL_
Thanks for your reply Kevin.
You explanation of why the most recent relay is ignored makes sense, thanks
for that.
I did try adding the "internal_networks 195.26.90. " option to my LOCAL.CF
before, an
) [195.26.90.113] which is also from the same range (only the final
numbers differ). Why is this? Why one and not the other? (I note that
in
all cases this final/most recent relay is never checked by SA actually.
Not
a problem, very glad of it, but dont know why).
This is because of how you&#x
, and then dealt
with accordingly based on the scores.
All normal stuff.
*
ENVIRONMENT*
The EXTERNAL HOST mail server is in on a subnet 195.26.90.xxx, and as such I
have marked this as an 'internal relay' in my MTA. This is so that when it
does its internal antispam checks, it then
On 2015-10-14 18:31, Mark Martinec wrote:
Check your database:
$ spamassassin --lint -D metadata' 2>&1 | fgrep RelayCountry
should yield something like:
Oct 15 01:26:45.584 [78315] dbg: metadata: RelayCountry:
Using database: Geo::IP GEO-106FREE 20151006 Build 1
Copyright (c) 2015 MaxMi
2015-10-15 00:09, a...@satester.com wrote:
Does the Geo::IP package need
to be recompiled for the change to go into effect?
No.
Use of uninitialized value $hasStructureInfo in numeric eq (==)
at (eval 31) line 5520
According to comments in Geo/IP.pm your GeoIP database files
must be very o
/geoip-api-perl/pull/22
If you click 'Files changed' you'll see the path, and see the fix.
On 10/14/15 11:49 AM, a...@satester.com wrote:
Hi,
We activated the relay country plugin yesterday. As part of the
process
we did a yum install perl-Geo-IP. Now we get the following warning
://github.com/maxmind/geoip-api-perl/pull/22
If you click 'Files changed' you'll see the path, and see the fix.
On 10/14/15 11:49 AM, a...@satester.com wrote:
Hi,
We activated the relay country plugin yesterday. As part of the
process
we did a yum install perl-Geo-IP. Now we get the fo
This?
https://github.com/maxmind/geoip-api-perl/pull/22
If you click 'Files changed' you'll see the path, and see the fix.
On 10/14/15 11:49 AM, a...@satester.com wrote:
> Hi,
>
> We activated the relay country plugin yesterday. As part of the process
> we did a yu
Hi,
We activated the relay country plugin yesterday. As part of the process
we did a yum install perl-Geo-IP. Now we get the following warning when
we lint or salearn.
Use of uninitialized value $hasStructureInfo in numeric eq (==) at (eval
31) line 5520
I have no idea which file line
On Wed, Oct 30, 2013 at 11:52:50AM -0700, John Hardin wrote:
>
> "Trust" here is not about "won't spam"
Btw trusted_networks entities haven't been checked in DNS blacklists since
2008... so in a sense it actually is an whitelist.. ;-)
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5856#
On Thu, Oct 31, 2013 at 11:45:45AM +0100, Matus UHLAR - fantomas wrote:
> >On Wed, Oct 30, 2013 at 11:52:50AM -0700, John Hardin wrote:
> >>"Trust" here is not about "won't spam", and ALL_TRUSTED is not a
> >>whitelist.
>
> On 31.10.13 10:59, Henrik K wrote:
> >Pfft semantics.
> >
> >I shortcircui
On Wed, Oct 30, 2013 at 11:52:50AM -0700, John Hardin wrote:
"Trust" here is not about "won't spam", and ALL_TRUSTED is not a
whitelist.
On 31.10.13 10:59, Henrik K wrote:
Pfft semantics.
I shortcircuit ALL_TRUSTED with a huge trusted_networks list. :-) So yes
it's a whitelist for me. I add
On Thu, Oct 31, 2013 at 9:59 AM, Henrik K wrote:
I shortcircuit ALL_TRUSTED with a huge trusted_networks list. :-) So yes
> it's a whitelist for me. I add networks known to be spam free and operated
> by "friends" (other govenment entities, consulting firms etc). Everything
> works fine, I've a
On Wed, Oct 30, 2013 at 11:52:50AM -0700, John Hardin wrote:
>
> "Trust" here is not about "won't spam", and ALL_TRUSTED is not a
> whitelist.
Pfft semantics.
I shortcircuit ALL_TRUSTED with a huge trusted_networks list. :-) So yes
it's a whitelist for me. I add networks known to be spam free an
On Wed, 2013-10-30 at 11:38 -0700, Thomas Johnson wrote:
> We have some users who would like to whitelist email based on the IP
> address of the last external relay. This is primarily for times like
> when messages are being sent from some webform they trust, or from
> internal syste
On Wed, 30 Oct 2013, Thomas Johnson wrote:
We have some users who would like to whitelist email based on the IP
address of the last external relay. This is primarily for times like when
messages are being sent from some webform they trust, or from internal
systems.
My first thought was to
We have some users who would like to whitelist email based on the IP
address of the last external relay. This is primarily for times like when
messages are being sent from some webform they trust, or from internal
systems.
My first thought was to simply add that IP to "trusted_networks"
On Wednesday March 6 2013 01:06:22 Scott Ostrander wrote:
> cd /usr/share/GeoIP
> wget -N
http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz
> gunzip GeoIP.dat.gz
Not to forget to download its IPv6 counterpart:
http://geolite.maxmind.com/download/geoip/database/Ge
> -Original Message-
> Sent: Tuesday, March 05, 2013 3:13 PM
> To: Scott Ostrander; Benny Pedersen; spamassassin
> Subject: Re: X-Relay-Countries on 3.3.2 vs 3.4
> >
> >
> > Is there a way to upgrade GeoIP ?
> I think you have to grab files from htt
On 3/5/13 2:15 PM, "Scott Ostrander" wrote:
>
>> From: Benny Pedersen [mailto:m...@junc.eu]
>>
>> Scott Ostrander skrev den 2013-03-05 20:22:
>>> On system A (SA 3.4) I am getting RELAY_COUNTRY_XX Same email on
>>> system B (SA 3.2.2) I get RELAY_COUNTRY_ES correctly resolved.
>>
>> ip2cc 2.1
Lutz Petersen skrev den 2013-03-05 21:44:
Simple question: If there is a need for locate the ip - why not use
the
well maintained countries.nerd.dk ?
one dns lookup pr sender recieved ip ?
i like to keep this trafic local, and nerd.dk have rsync shareing last
time i did it, but did not like
Scott Ostrander skrev den 2013-03-05 21:40:
On system A (SA 3.4) I removed Geo::IP and it now correctly resolves
the Relay-Country as ES
Looks like I will have to keep manually updating IP::Country::Fast
;(
[I] dev-libs/geoip
Available versions: 1.4.8-r1 1.4.8-r2 ~1.4.8-r3 {{city
> > ip::country::fast is depricated alone since its not update with new ips, it
> > still
> > works if your still have ipv4 mailserver and self do updates with dbmscript
>
> On system A (SA 3.4) I removed Geo::IP and it now correctly resolves the
> Relay-Country as
> -Original Message-
> Sent: Tuesday, March 05, 2013 12:37 PM
> To: users@spamassassin.apache.org
> Subject: RE: X-Relay-Countries on 3.3.2 vs 3.4
>
> Scott Ostrander skrev den 2013-03-05 21:15:
>
> plase fix your reply template, replyed sender email should
Scott Ostrander skrev den 2013-03-05 21:15:
From: Benny Pedersen [mailto:m...@junc.eu]
plase fix your reply template, replyed sender email should not be in
body content
However system A (3.4) also has GeoIP installed as suggested at
http://wiki.apache.org/spamassassin/RelayCountryPlugin
Is
1 - 100 of 319 matches
Mail list logo
