Re: X-Relay-Countries not working
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 untrusted relay is...'. It assumes some knowledge of regex syntax that is all.
Re: X-Relay-Countries not working
This was it. You guys are the best. Thanks so much. Regards Brent On 2018/11/28 08:26, Dominic Raferd wrote: On Wed, 28 Nov 2018 at 06:15, Brent Clark <mailto:brentgclarkl...@gmail.com>> wrote: Thanks for replying I did as you asked, here is the pastebin https://pastebin.com/XqSXndpW I could not see anything like you describe (i.e "I've found that the plugin will fallback 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 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.
Re: X-Relay-Countries not working
On Wed, 28 Nov 2018 at 06:15, Brent Clark wrote: > Thanks for replying > > I did as you asked, here is the pastebin > > https://pastebin.com/XqSXndpW > > I could not see anything like you describe (i.e "I've found that the > plugin will fallback 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 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.
Re: X-Relay-Countries not working
Try removing the eval in the actual code that calls the database file temporarily and check if there are perl modules missing. I‘ve been there too and had to install some maxmind reader and database modules. If they are missing, you‘ll see an error in the debug log then. Vitali > Am 28.11.2018 um 07:15 schrieb Brent Clark : > > Thanks for replying > > I did as you asked, here is the pastebin > > https://pastebin.com/XqSXndpW > > I could not see anything like you describe (i.e "I've found that the plugin > will fallback 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 > > I am at a complete loss on this one. > > Thanks in advance for your help. > > Regards > Brent > > > >> On 2018/11/27 16:02, RW wrote: >> On Tue, 27 Nov 2018 12:51:40 +0200 >> Brent Clark wrote: >>> 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 >> 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 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 Relay-Country _RELAYCOUNTRY_ >>> >>> In my testing, I added ZA, and it picked up for IP 196.35.198.137. >>> >>> Also, does anyone know why the 27.102.212.207 is in square brackets. >> Usually it's to indicate that it's an IP address.
Re: X-Relay-Countries not working
Thanks for replying I did as you asked, here is the pastebin https://pastebin.com/XqSXndpW I could not see anything like you describe (i.e "I've found that the plugin will fallback 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 I am at a complete loss on this one. Thanks in advance for your help. Regards Brent On 2018/11/27 16:02, RW wrote: On Tue, 27 Nov 2018 12:51:40 +0200 Brent Clark wrote: 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 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 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 Relay-Country _RELAYCOUNTRY_ In my testing, I added ZA, and it picked up for IP 196.35.198.137. Also, does anyone know why the 27.102.212.207 is in square brackets. Usually it's to indicate that it's an IP address.
Re: X-Relay-Countries not working
On Tue, 27 Nov 2018 12:51:40 +0200 Brent Clark wrote: > 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 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 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 Relay-Country _RELAYCOUNTRY_ > > In my testing, I added ZA, and it picked up for IP 196.35.198.137. > > Also, does anyone know why the 27.102.212.207 is in square brackets. Usually it's to indicate that it's an IP address.
Re: X-Relay-Countries not working
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)/ describe RELAYCOUNTRY_BAD Relayed through foreign countries scoreRELAYCOUNTRY_BAD 1.0 add_header all Relay-Country _RELAYCOUNTRY_ In my testing, I added ZA, and it picked up for IP 196.35.198.137. Also, does anyone know why the 27.102.212.207 is in square brackets. Geoip pics up: $ geoiplookup 27.102.212.207 GeoIP Country Edition: KR, Korea, Republic of Would anyone please share a rule, I can use to catch the above spam. tried runinning "spamassassin -D" over the e-mail? just to see if it picks the rule, if it finds the database etc -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
X-Relay-Countries not working
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 Relayed through foreign countries scoreRELAYCOUNTRY_BAD 1.0 add_header all Relay-Country _RELAYCOUNTRY_ In my testing, I added ZA, and it picked up for IP 196.35.198.137. Also, does anyone know why the 27.102.212.207 is in square brackets. Geoip pics up: $ geoiplookup 27.102.212.207 GeoIP Country Edition: KR, Korea, Republic of Would anyone please share a rule, I can use to catch the above spam. Regards Brent Clark P.s. Im running spamassassin 3.4.2-1~deb9u1
X-Relay-Countries on 3.3.2 vs 3.4
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. System A is Centos6 SA 3.4.0-r1435395 perl-Geo-IP-1.38-6 perl-IP-Country-2.27-1 With updated cc.gif and ip.gif from http://mailfud.org/ip-country-fast/ System A is working on other emails giving me X-Spam-Relay-Country: US ** System B is Centos5 SA 3.3.2 perl-IP-Country-2.27-1 With updated cc.gif and ip.gif from http://mailfud.org/ip-country-fast/ My understanding is that SA 3.4 it will use GeoIP first if found. Is there a need to update GeoIP like perl-IP-Country? If so how? Any other insights on how to get SA 3.4 to resolve this Relay-Country? The email with this issue is at http://pastebin.com/vFfEuY3A Thanks, Scott Ostrander
Re: X-Relay-Countries on 3.3.2 vs 3.4
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.104.223.10 if not found you need updates XX is imho ip is not in use
RE: X-Relay-Countries on 3.3.2 vs 3.4
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.104.223.10 if not found you need updates XX is imho ip is not in use On both systems I get: # Ip2cc 146.255.100.187 Country: ES (Spain) However system A (3.4) also has GeoIP installed as suggested at http://wiki.apache.org/spamassassin/RelayCountryPlugin Is there a way to upgrade GeoIP ? Or should I just remove Geo::IP as it appears that it is not keeping up with the updates like IP::Country::Fast
RE: X-Relay-Countries on 3.3.2 vs 3.4
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 there a way to upgrade GeoIP ? Or should I just remove Geo::IP as it appears that it is not keeping up with the updates like IP::Country::Fast this will be backwards if you keep the latest 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
RE: X-Relay-Countries on 3.3.2 vs 3.4
-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 not be in body content However system A (3.4) also has GeoIP installed as suggested at http://wiki.apache.org/spamassassin/RelayCountryPlugin Is there a way to upgrade GeoIP ? Or should I just remove Geo::IP as it appears that it is not keeping up with the updates like IP::Country::Fast this will be backwards if you keep the latest 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 ES Looks like I will have to keep manually updating IP::Country::Fast ;( Scott Ostrander
Re: X-Relay-Countries on 3.3.2 vs 3.4
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 ES Looks like I will have to keep manually updating IP::Country::Fast ;( Simple question: If there is a need for locate the ip - why not use the well maintained countries.nerd.dk ?
RE: X-Relay-Countries on 3.3.2 vs 3.4
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 ipv6
perl-geoipupdate static-libs}}
Installed versions: 1.4.8-r2(01:12:07
26-01-2013)(perl-geoipupdate -ipv6 -static-libs)
Homepage:http://www.maxmind.com/app/ip-location
Description: easily lookup countries by IP addresses, even
when Reverse DNS entries don't exist
this is what i use with gentoo, it contains an perl script for updates
:)
Re: X-Relay-Countries on 3.3.2 vs 3.4
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 to keep this self maintained rules :)
Re: X-Relay-Countries on 3.3.2 vs 3.4
On 3/5/13 2:15 PM, Scott Ostrander sostran...@printronix.com 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.104.223.10 if not found you need updates XX is imho ip is not in use On both systems I get: # Ip2cc 146.255.100.187 Country: ES (Spain) However system A (3.4) also has GeoIP installed as suggested at http://wiki.apache.org/spamassassin/RelayCountryPlugin Is there a way to upgrade GeoIP ? I think you have to grab files from http://dev.maxmind.com/geoip/geolite Maxmind says they update them on the first Tuesday of each month. The RPM on mageia 2 has a crontab entry in /etc/cron/monthly that runs on the first day of the month, meaning that the data will be 3-7 weeks old. It appears to grab GeoIP.dat, GeoIPv6.dat, and GeoLiteCity.dat Or should I just remove Geo::IP as it appears that it is not keeping up with the updates like IP::Country::Fast
RE: X-Relay-Countries on 3.3.2 vs 3.4
-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 http://dev.maxmind.com/geoip/geolite Maxmind says they update them on the first Tuesday of each month. The RPM on mageia 2 has a crontab entry in /etc/cron/monthly that runs on the first day of the month, meaning that the data will be 3-7 weeks old. It appears to grab GeoIP.dat, GeoIPv6.dat, and GeoLiteCity.dat Yes, the DB update to GeoIP worked. SA 3.4 with Geo::IP now gives the correct answer. To check from the command line I used: (which failed before the DB update) /usr/bin/geoiplookup 146.255.100.187 GeoIP Country Edition: ES, Spain To update the DB on CentOS I did the following: cd /usr/share/GeoIP wget -N http://geolite.maxmind.com/download/geoip/database/GeoLiteCountry/GeoIP.dat.gz gunzip GeoIP.dat.gz Thanks for the help, Scott Ostrander
Re: X-Relay-Countries on 3.3.2 vs 3.4
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/GeoIPv6.dat.gz Even if not running an IPv6 MTA, there may be IPv6 addresses in Received header fields. The GeoIP (with SA 3.4) handles both address families. Mark
Re: X-Relay-Countries
On 2/16/13 8:10 AM, Henrik K h...@hege.li wrote: Well I updated http://mailfud.org/ip-country-fast/ for the last time.. (no, you don't need the authorities gifs) There is no excuse not using SpamAssassin 3.4 with Geo::IP support (also ipv6 works). Like the wiki says. 45 open bugs targeted for that version, 5 of them blockers? Sounds like a valid excuse to me. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281
Re: X-Relay-Countries
On Mon, Feb 18, 2013 at 07:18:17AM -0600, Daniel McDonald wrote: On 2/16/13 8:10 AM, Henrik K h...@hege.li wrote: Well I updated http://mailfud.org/ip-country-fast/ for the last time.. (no, you don't need the authorities gifs) There is no excuse not using SpamAssassin 3.4 with Geo::IP support (also ipv6 works). Like the wiki says. 45 open bugs targeted for that version, 5 of them blockers? Sounds like a valid excuse to me. Eh, anyone that actually follows how development is going, SVN has been used by many people (not least all developers) for a year if not several. It has worked much better than 3.3 for a long time.
Re: X-Relay-Countries
Walter Hurry skrev den 2013-02-15 19:59: So I have up-to-date ip.gif and cc.gif. If anyone wants them, post here and I'll put them on an ftp site somewhere. nope its faster to get 4GB ram and build localy, and its creates 4 gif files not just 2 as in the wiki says, this plugin is ok for ipv4 only mailhosts, but if mailhost have ipv6 either need this module patched to ipv6 or change to geo-ip closed sources, with possible diffrent licenses then apache uses in spamassassin
Re: X-Relay-Countries
On Sat, Feb 16, 2013 at 12:21:55PM +0100, Benny Pedersen wrote: Walter Hurry skrev den 2013-02-15 19:59: So I have up-to-date ip.gif and cc.gif. If anyone wants them, post here and I'll put them on an ftp site somewhere. nope its faster to get 4GB ram and build localy, and its creates 4 gif files not just 2 as in the wiki says, this plugin is ok for ipv4 only mailhosts, but if mailhost have ipv6 either need this module patched to ipv6 or change to geo-ip closed sources, with possible diffrent licenses then apache uses in spamassassin World record for long sentence? Well I updated http://mailfud.org/ip-country-fast/ for the last time.. (no, you don't need the authorities gifs) There is no excuse not using SpamAssassin 3.4 with Geo::IP support (also ipv6 works). Like the wiki says.
Re: X-Relay-Countries
On Thu, 14 Feb 2013 13:26:33 +0100, Benny Pedersen wrote:
Steve Freegard skrev den 2013-02-12 21:19:
header RELAY_NOT_US X-Relay-Countries =~ /\b(?!US)[A-Z]{2}\b/
and what date is the database from ?, ip2cc ipv4-addr, to show it when
its build, to update it either use the new relay_country plugin or
update ip2cc database, if its over 6 mounts its time for a change
The former option wasn't really available for me, so I followed the notes
at http://wiki.apache.org/spamassassin/RelayCountryPlugin as suggested by
Jeff Mincy.
First I installed IP::Country::Fast, and noted that the database was from
July 2009. So I downloaded the two files from
http://mailfud.org/ip-country-fast/ as mentioned in the wiki article.
Better: June 2012.
Finally I built them myself using the RIPE downloads, again as suggested
in the wiki article.
$ ip2cc 213.174.72.92
IP::Country modules (v2.27)
Copyright (c) 2002-05 Nigel Wetters Gourlay
Database updated Fri Feb 15 18:04:48 2013
Address: 213.174.72.92
Country: DK (Denmark)
$
So I have up-to-date ip.gif and cc.gif. If anyone wants them, post here
and I'll put them on an ftp site somewhere.
Re: X-Relay-Countries
On 12/02/13 20:33, Daniel McDonald wrote: On 2/12/13 1:15 PM, David F. Skolld...@roaringpenguin.com wrote: PS: Beware of penalizing other countries too much. My mail originates from Canada and the PostgreSQL mailing list is (or used to be?) hosted in Panama. Furthermore, by far the lion's share of spam originates from the US. Yes, of course. But some mail just isn't likely to originate overseas. For example, we have been getting a lot of phishes pretending to be FedEX non-delivery notices. FedEX is based in the US, so if I see FedEX and RELAY_NOT_US, and a couple of other spam signs, I can more safely conclude it is spam Nice idea, but why not just use SPF for fedex.com as they bother to publish an SPF record? Surely that has to be a far more reliable indicator it wasn't sent from fedex? $ dig txt fedex.com ;; ANSWER SECTION: fedex.com. 10578 IN TXT v=spf1 redirect=_spf.infosec.fedex.com They might sign their mail too, but as I don't have any legitimate fedex mails to hand, I can't confirm that.
Re: X-Relay-Countries
Steve Freegard skrev den 2013-02-12 21:19:
header RELAY_NOT_US X-Relay-Countries =~ /\b(?!US)[A-Z]{2}\b/
and what date is the database from ?, ip2cc ipv4-addr, to show it when
its build, to update it either use the new relay_country plugin or
update ip2cc database, if its over 6 mounts its time for a change
Re: X-Relay-Countries
On 2/14/13 6:21 AM, Ned Slider n...@unixmail.co.uk wrote: On 12/02/13 20:33, Daniel McDonald wrote: On 2/12/13 1:15 PM, David F. Skolld...@roaringpenguin.com wrote: PS: Beware of penalizing other countries too much. My mail originates from Canada and the PostgreSQL mailing list is (or used to be?) hosted in Panama. Furthermore, by far the lion's share of spam originates from the US. Yes, of course. But some mail just isn't likely to originate overseas. For example, we have been getting a lot of phishes pretending to be FedEX non-delivery notices. FedEX is based in the US, so if I see FedEX and RELAY_NOT_US, and a couple of other spam signs, I can more safely conclude it is spam Nice idea, but why not just use SPF for fedex.com as they bother to publish an SPF record? Surely that has to be a far more reliable indicator it wasn't sent from fedex? $ dig txt fedex.com ;; ANSWER SECTION: fedex.com. 10578 IN TXT v=spf1 redirect=_spf.infosec.fedex.com They might sign their mail too, but as I don't have any legitimate fedex mails to hand, I can't confirm that. We get plenty of messages from suppliers stating that they have made a shipment, and the fedex tracking number is foo. But lately we've been getting a lot of phishes where the link for the fedex tracking number actually points to malware, and most of these are using cracked accounts and are being generated on botnets, so I'm looking for a fedex tracking link that didn't originate locally. -- Daniel J McDonald, CCIE # 2495, CISSP # 78281
Re: X-Relay-Countries
On Thu, 14 Feb 2013 12:21:33 + Ned Slider n...@unixmail.co.uk wrote: Nice idea, but why not just use SPF for fedex.com as they bother to publish an SPF record? Surely that has to be a far more reliable indicator it wasn't sent from fedex? That works if the envelope sender is someth...@fedex.com, but if the header sender is from fedex.com and the envelope sender is spam...@passes-spf.org then SPF is useless. I experimented with applying SPF tests to the header From: (which is against the spec), but it had way too many false-positives. They might sign their mail too, but as I don't have any legitimate fedex mails to hand, I can't confirm that. I don't believe they use DKIM. Regards, David.
X-Relay-Countries
I¹ve had a simple rule I use to see if mail is forwarded through a ³foreign
country²:
header RELAY_NOT_USX-Relay-Countries =~
/\b(?:[ABCDEFGHIJKLMNOPQRTVWXYZ]{2}|\b/
describeRELAY_NOT_USRelayed though any country other than the US
score RELAY_NOT_US0.01
I mostly use it in Meta¹s, but it¹s a nice flag when doing other
correlations.
Unfortunately, the perl expression doesn¹t work for countries like the
Ukraine (UA) or Russia (RU).
And I don¹t really want ! RELAY_US, for lots of reasons.
Can someone suggest an expression that will match any 2-capital letter word
other than US?
--
Daniel J McDonald, CCIE # 2495, CISSP # 78281
Re: X-Relay-Countries
On 2/12/13 12:47 PM, Daniel McDonald dan.mcdon...@austinenergy.com
wrote:
I¹ve had a simple rule I use to see if mail is forwarded through a ³foreign
country²:
header RELAY_NOT_USX-Relay-Countries =~
/\b(?:[ABCDEFGHIJKLMNOPQRTVWXYZ]{2}|\b/
Oops. I was fiddling with the syntax trying to fix it. This is my current
rule:
header RELAY_NOT_US X-Relay-Countries =~ /\b[ABCDEFGHIJKLMNOPQRTVWXYZ]{2}\b/
--
Daniel J McDonald, CCIE # 2495, CISSP # 78281
Re: X-Relay-Countries
On Tue, 12 Feb 2013 12:58:40 -0600
Daniel McDonald dan.mcdon...@austinenergy.com wrote:
header RELAY_NOT_US X-Relay-Countries =~ /\b[ABCDEFGHIJKLMNOPQRTVWXYZ]{2}\b/
How about:
header RELAY_NOT_US X-Relay-Countries =~ /\b(?:[A-TW-Z][A-Z]|[A-Z][A-RT-Z])\b/
Untested; use at your own risk. :)
Regards,
David.
PS: Beware of penalizing other countries too much. My mail originates
from Canada and the PostgreSQL mailing list is (or used to be?) hosted
in Panama. Furthermore, by far the lion's share of spam originates from
the US.
Re: X-Relay-Countries
On Tue, 12 Feb 2013 14:14:46 -0500 David F. Skoll d...@roaringpenguin.com wrote: header RELAY_NOT_US X-Relay-Countries =~ /\b(?:[A-TW-Z][A-Z]|[A-Z][A-RT-Z])\b/ Emm... should be header RELAY_NOT_US X-Relay-Countries =~ /\b(?:[A-TV-Z][A-Z]|[A-Z][A-RT-Z])\b/ of course. Sorry! Regards, David.
Re: X-Relay-Countries
On Tue, 2013-02-12 at 14:15 -0500, David F. Skoll wrote: header RELAY_NOT_US X-Relay-Countries =~ /\b(?:[A-TV-Z][A-Z]|[A-Z][A-RT-Z])\b/ Shouldn't that be: header RELAY_NOT_US X-Relay-Countries=~ /\b(?:[A-TV-Z][A-RT-Z])\b/ of course. Sorry! BTW, its no wonder so much spam cones from the US since CANSPAM seems to be utterly toothless. It reminds me of the Telephone Preference Service here, which is supposed to block unwanted cold calls from telemarketers but in practise all it does is to make apologetic noises. Martin
Re: X-Relay-Countries
On Tue, 12 Feb 2013 19:57:28 + Martin Gregorie mar...@gregorie.org wrote: header RELAY_NOT_US X-Relay-Countries=~ /\b(?:[A-TV-Z][A-RT-Z])\b/ No. We leave it as an exercise to the reader to find out why that solution is wrong. Regards, David.
Re: X-Relay-Countries
On 2/12/2013 3:00 PM, David F. Skoll wrote:
On Tue, 12 Feb 2013 19:57:28 +
Martin Gregorie mar...@gregorie.org wrote:
header RELAY_NOT_US X-Relay-Countries=~ /\b(?:[A-TV-Z][A-RT-Z])\b/
No. We leave it as an exercise to the reader to find out why that
solution is wrong.
Hmm I would do something like this (untested):
header RELAY_NOT_US X-Relay-Countries =~ /\b(?!US)[A-Z]{2}\b/
--
Bowie
Re: X-Relay-Countries
Hmm I would do something like this (untested):
header RELAY_NOT_US X-Relay-Countries =~ /\b(?!US)[A-Z]{2}\b/
I've had to use, IIRC.
X-Relay-Countries =~ /\b(?!US|XX)([A-Z]{2})\b/
Re: X-Relay-Countries
On 12/02/13 18:47, Daniel McDonald wrote:
I’ve had a simple rule I use to see if mail is forwarded through a
“foreign country”:
header RELAY_NOT_USX-Relay-Countries =~
/\b(?:[ABCDEFGHIJKLMNOPQRTVWXYZ]{2}|\b/
describeRELAY_NOT_USRelayed though any country other than the US
score RELAY_NOT_US0.01
I mostly use it in Meta’s, but it’s a nice flag when doing other
correlations.
Unfortunately, the perl expression doesn’t work for countries like the
Ukraine (UA) or Russia (RU).
And I don’t really want ! RELAY_US, for lots of reasons.
Can someone suggest an expression that will match any 2-capital letter
word other than US?
How about:
header RELAY_NOT_US X-Relay-Countries =~ /\b(?!US)[A-Z]{2}\b/
Regards,
Steve.
Re: X-Relay-Countries
On 2/12/13 1:15 PM, David F. Skoll d...@roaringpenguin.com wrote: On Tue, 12 Feb 2013 14:14:46 -0500 David F. Skoll d...@roaringpenguin.com wrote: header RELAY_NOT_US X-Relay-Countries =~ /\b(?:[A-TW-Z][A-Z]|[A-Z][A-RT-Z])\b/ Emm... should be header RELAY_NOT_US X-Relay-Countries =~ /\b(?:[A-TV-Z][A-Z]|[A-Z][A-RT-Z])\b/ Quite right, and quite simple. Thanks! PS: Beware of penalizing other countries too much. My mail originates from Canada and the PostgreSQL mailing list is (or used to be?) hosted in Panama. Furthermore, by far the lion's share of spam originates from the US. Yes, of course. But some mail just isn't likely to originate overseas. For example, we have been getting a lot of phishes pretending to be FedEX non-delivery notices. FedEX is based in the US, so if I see FedEX and RELAY_NOT_US, and a couple of other spam signs, I can more safely conclude it is spam
Re: X-Relay-Countries
From: Mike Grau m.g...@kcc.state.ks.us
Date: Tue, 12 Feb 2013 14:18:33 -0600
Hmm I would do something like this (untested):
header RELAY_NOT_US X-Relay-Countries =~ /\b(?!US)[A-Z]{2}\b/
I've had to use, IIRC.
X-Relay-Countries =~ /\b(?!US|XX)([A-Z]{2})\b/
XX means unknown, mostly due to stale database. You can update the
IP::Country database. See:
http://wiki.apache.org/spamassassin/RelayCountryPlugin
-jeff
X-Relay-Countries can stick?
Is there anyway to get his header to stick rather than one looks like now where it is removed during check presumably after Bayes has been able to do it's thing? I have no problem with the header staying on my Spam messages.
Re: X-Relay-Countries can stick?
For instance when I run my test I see Feb 12 17:20:38.634 [16073] dbg: metadata: X-Relay-Countries: RU Feb 12 17:20:38.634 [16073] dbg: message: MIME PARSER START Feb 12 17:20:38.635 [16073] dbg: message: parsing normal part Feb 12 17:20:38.635 [16073] dbg: message: MIME PARSER END Feb 12 17:20:38.635 [16073] dbg: message: decoding other encoding type (binary), ignoring in the debug output but I don't see this header in the final message that had it's metadata added. On Feb 12, 2010, at 7:24 PM, Robert Nicholson wrote: Is there anyway to get his header to stick rather than one looks like now where it is removed during check presumably after Bayes has been able to do it's thing? I have no problem with the header staying on my Spam messages.
Re: X-Relay-Countries can stick?
Perhaps my confusion lies in the fact that it looks like headers != metadata? Is there a way or setting that allows metadata to result in headers in the message? On Feb 12, 2010, at 7:24 PM, Robert Nicholson wrote: Is there anyway to get his header to stick rather than one looks like now where it is removed during check presumably after Bayes has been able to do it's thing? I have no problem with the header staying on my Spam messages.
Re: X-Relay-Countries can stick?
From: Robert Nicholson robert.nichol...@gmail.com Date: Fri, 12 Feb 2010 19:32:00 -0600 Perhaps my confusion lies in the fact that it looks like headers != metadata? Is there a way or setting that allows metadata to result in headers in the message? Did you try add_header? ifplugin Mail::SpamAssassin::Plugin::RelayCountry add_header all Relay-Country _RELAYCOUNTRY_ endif
Re: X-Relay-Countries can stick?
On Fri, 12 Feb 2010 19:32:00 -0600 Robert Nicholson robert.nichol...@gmail.com wrote: Perhaps my confusion lies in the fact that it looks like headers != metadata? Is there a way or setting that allows metadata to result in headers in the message? add_header all Relay-Countries _RELAYCOUNTRY
