Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
In the future, if you're not prepared to show the actual problem with their actual data, please don't waste our time. You know that's the sort of thing I hate about the Open Source community, the big ego trips by the crusty old dudes who've been around forever and enjoy giving the relative newbies a hard time. I lost count of how many times I apologised to the list for not making it clear in my original post. Everyone else seemed to accept that apology, but obviously you're one of those hard-core mailing list guys who would rather see me sent to the gallows for what was a pretty minor error in the grand scheme of things.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Alternatively, I pulled fire alarms at Microsoft and it is very possible people at Spamhaus also spent reacting to your email because of the erroneous information posted. So while John may have been slightly impolitic,and fairly rude, he isn't wrong, and it isn't about ego (in this case). I cannot comment as to his current state of crust, will advise. On Aug 16, 2013, at 7:06 AM, Nigel Smith gb10hkzo-...@yahoo.co.uk wrote: In the future, if you're not prepared to show the actual problem with their actual data, please don't waste our time. You know that's the sort of thing I hate about the Open Source community, the big ego trips by the crusty old dudes who've been around forever and enjoy giving the relative newbies a hard time. I lost count of how many times I apologised to the list for not making it clear in my original post. Everyone else seemed to accept that apology, but obviously you're one of those hard-core mailing list guys who would rather see me sent to the gallows for what was a pretty minor error in the grand scheme of things.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Yes, I have checked on the real Zen lists and the real IP is there. Then your checking software is broken. None of the Spamhaus lists ever include anything in 10/8. John, the big hint was in the word *REAL IP*... as I said hundreds of times subsequently to the initial post, I stupidly forgot to mention in my original post that I obfuscated the first to octets of the IP into RFC1918 range. Yes, my bad, yes I should have said but I did tell everyone multiple times subsequently, I think you must have skipped over my subsequent posts. Anyway, back to the topic, I rolled out some new configs yesterday evening based on some of the suggestions received here, so will see how things pan out today.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Oh, OK. In the future, if you're not prepared to show the actual problem with their actual data, please don't waste our time. R's from a thing with no keyboard, John Nigel Smith gb10hkzo-...@yahoo.co.uk wrote: Yes, I have checked on the real Zen lists and the real IP is there. Then your checking software is broken. None of the Spamhaus lists ever include anything in 10/8. John, the big hint was in the word *REAL IP*... as I said hundreds of times subsequently to the initial post, I stupidly forgot to mention in my original post that I obfuscated the first to octets of the IP into RFC1918 range. Yes, my bad, yes I should have said but I did tell everyone multiple times subsequently, I think you must have skipped over my subsequent posts. Anyway, back to the topic, I rolled out some new configs yesterday evening based on some of the suggestions received here, so will see how things pan out today.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 8/14/2013 9:49 AM, Nigel Smith wrote:
Hi,
SpamAssassin version 3.3.2
running on Perl version 5.14.2
3.2.0-49-generic #75-Ubuntu SMP Tue Jun 18 17:39:32 UTC 2013 x86_64
x86_64 x86_64 GNU/Linux
(ubuntu 12.04LTS)
I'm having some major problems at the moment with people who send mail
via their corporate email platforms hosted on Microsoft's Bigfish
(a.ka. FrontBridge, or whatever they're choosing to call it today !).
The problem seems to be a conflict something in one of the headers
Microsoft add :
X-Forefront-Antispam-Report-Untrusted:
SFV:NSPM;SFS:(24454002)(377454003)(51704005)(199002)(189002)(16406001)(54356001)(69226001)(74876001)(79102001)(4396001)(81542001)(49866001)(47736001)(47446002)(31966008)(74662001)(74502001)(81342001)(76482001)(80976001)(56776001)(54316002)(53806001)(74706001)(77096001)(56816003)(66066001)(80022001)(65816001)(77982001)(59766001)(74366001)(51856001)(46102001)(36756003)(63696002)(50986001)(47976001)(19580395003)(19580405001)(83072001)(76796001)(83322001)(33656001)(76786001)(81686001)(81816001);DIR:OUT;SFP:;SCL:1;SRVR:BLUPR03MB003;H:BLUPR03MB001.namprd03.prod.outlook.com;CLIP:10.10.114.156;RD:InfoNoRecords;A:1;MX:1;LANG:en;
x-originating-ip: [10.10.114.156]
X-MS-Exchange-CrossPremises-originalclientipaddress: 10.10.114.156
And one of my SA rules :
# Locally hosted Spamhaus
score __RCVD_IN_ZEN 0
header ITS_RCVD_IN_ZENeval:check_rbl('zen', 'zen.dnsbl.')
describe ITS_RCVD_IN_ZEN Received via a relay in Spamhaus Zen
tflags ITS_RCVD_IN_ZENnet
reuse ITS_RCVD_IN_ZEN
score ITS_RCVD_IN_ZEN 30.0
This triggers :
* 30 ITS_RCVD_IN_ZEN RBL: Received via a relay in Spamhaus Zen
* [10.10.114.156 listed in zen.dnsbl]
The only place that IP can be found (i.e. cat spam-97InS+5ooirt | grep
10.10.114.156) is in the three headers above. The rcvd lines do not
match.
10.X is a private network. Why is Zen listing it?
Have you checked that IP on the real Zen listing and not on your cached
server?
regards,
KAM
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 8/14/2013 10:14 AM, Jeremy McSpadden wrote: http://www.spamhaus.org/query/ip/10.10.114.156 * * * 10.10.114.156 is not listed in the SBL* *10.10.114.156 is not listed in the PBL* *10.10.114.156 is not listed in the XBL* Then I would say you have something in your DNS infrastructure that is returning FPs on your zen queries OR it has already been resolved by Spamhaus. If you query it manually through your DNS infrastructure what do you get? Regards, KAM
RE: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
http://www.spamhaus.org/query/ip/10.10.114.156
10.10.114.156 is not listed in the SBL
10.10.114.156 is not listed in the PBL
10.10.114.156 is not listed in the XBL
Cheers,
Phil
--
Phil Randal
Infrastructure Engineer
Hoople Ltd | Thorn Office Centre | Hereford HR2 6JT
Tel: 01432 260415 | Email:
phil.ran...@hoopleltd.co.ukmailto:phil.ran...@hoopleltd.co.uk
From: Kevin A. McGrail [mailto:kmcgr...@pccc.com]
Sent: 14 August 2013 15:11
To: Nigel Smith
Cc: users@spamassassin.apache.org
Subject: Re: Big problems with senders who use Microsoft Bigfish (a.k.a.
FrontBridge)
On 8/14/2013 9:49 AM, Nigel Smith wrote:
Hi,
SpamAssassin version 3.3.2
running on Perl version 5.14.2
3.2.0-49-generic #75-Ubuntu SMP Tue Jun 18 17:39:32 UTC 2013 x86_64 x86_64
x86_64 GNU/Linux
(ubuntu 12.04LTS)
I'm having some major problems at the moment with people who send mail via
their corporate email platforms hosted on Microsoft's Bigfish (a.ka.
FrontBridge, or whatever they're choosing to call it today !).
The problem seems to be a conflict something in one of the headers Microsoft
add :
X-Forefront-Antispam-Report-Untrusted:
SFV:NSPM;SFS:(24454002)(377454003)(51704005)(199002)(189002)(16406001)(54356001)(69226001)(74876001)(79102001)(4396001)(81542001)(49866001)(47736001)(47446002)(31966008)(74662001)(74502001)(81342001)(76482001)(80976001)(56776001)(54316002)(53806001)(74706001)(77096001)(56816003)(66066001)(80022001)(65816001)(77982001)(59766001)(74366001)(51856001)(46102001)(36756003)(63696002)(50986001)(47976001)(19580395003)(19580405001)(83072001)(76796001)(83322001)(33656001)(76786001)(81686001)(81816001);DIR:OUT;SFP:;SCL:1;SRVR:BLUPR03MB003;H:BLUPR03MB001.namprd03.prod.outlook.com;CLIP:10.10.114.156;RD:InfoNoRecords;A:1;MX:1;LANG:en;
x-originating-ip: [10.10.114.156]
X-MS-Exchange-CrossPremises-originalclientipaddress: 10.10.114.156
And one of my SA rules :
# Locally hosted Spamhaus
score __RCVD_IN_ZEN 0
header ITS_RCVD_IN_ZENeval:check_rbl('zen', 'zen.dnsbl.')
describe ITS_RCVD_IN_ZEN Received via a relay in Spamhaus Zen
tflags ITS_RCVD_IN_ZENnet
reuse ITS_RCVD_IN_ZEN
score ITS_RCVD_IN_ZEN 30.0
This triggers :
* 30 ITS_RCVD_IN_ZEN RBL: Received via a relay in Spamhaus Zen
* [10.10.114.156 listed in zen.dnsbl]
The only place that IP can be found (i.e. cat spam-97InS+5ooirt | grep
10.10.114.156) is in the three headers above. The rcvd lines do not match.
10.X is a private network. Why is Zen listing it?
Have you checked that IP on the real Zen listing and not on your cached server?
regards,
KAM
Hoople Ltd, Registered in England and Wales No. 7556595
Registered office: Plough Lane, Hereford, HR4 0LE
Any opinion expressed in this e-mail or any attached files are those of the
individual and not necessarily those of Hoople Ltd. You should be aware that
Hoople Ltd. monitors its email service. This e-mail and any attached files are
confidential and intended solely for the use of the addressee. This
communication may contain material protected by law from being passed on. If
you are not the intended recipient and have received this e-mail in error, you
are advised that any use, dissemination, forwarding, printing or copying of
this e-mail is strictly prohibited. If you have received this e-mail in error
please contact the sender immediately and destroy all copies of it.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 08/14/2013 03:49 PM, Nigel Smith wrote:
Hi,
SpamAssassin version 3.3.2
running on Perl version 5.14.2
3.2.0-49-generic #75-Ubuntu SMP Tue Jun 18 17:39:32 UTC 2013 x86_64 x86_64
x86_64 GNU/Linux
(ubuntu 12.04LTS)
I'm having some major problems at the moment with people who send mail via
their corporate email platforms hosted on Microsoft's Bigfish (a.ka.
FrontBridge, or whatever they're choosing to call it today !).
The problem seems to be a conflict something in one of the headers Microsoft
add :
X-Forefront-Antispam-Report-Untrusted:
SFV:NSPM;SFS:(24454002)(377454003)(51704005)(199002)(189002)(16406001)(54356001)(69226001)(74876001)(79102001)(4396001)(81542001)(49866001)(47736001)(47446002)(31966008)(74662001)(74502001)(81342001)(76482001)(80976001)(56776001)(54316002)(53806001)(74706001)(77096001)(56816003)(66066001)(80022001)(65816001)(77982001)(59766001)(74366001)(51856001)(46102001)(36756003)(63696002)(50986001)(47976001)(19580395003)(19580405001)(83072001)(76796001)(83322001)(33656001)(76786001)(81686001)(81816001);DIR:OUT;SFP:;SCL:1;SRVR:BLUPR03MB003;H:BLUPR03MB001.namprd03.prod.outlook.com;CLIP:10.10.114.156;RD:InfoNoRecords;A:1;MX:1;LANG:en;
x-originating-ip: [10.10.114.156]
X-MS-Exchange-CrossPremises-originalclientipaddress: 10.10.114.156
And one of my SA rules :
# Locally hosted Spamhaus
score __RCVD_IN_ZEN 0
header ITS_RCVD_IN_ZENeval:check_rbl('zen', 'zen.dnsbl.')
describe ITS_RCVD_IN_ZEN Received via a relay in Spamhaus Zen
tflags ITS_RCVD_IN_ZENnet
reuse ITS_RCVD_IN_ZEN
score ITS_RCVD_IN_ZEN 30.0
This triggers :
* 30 ITS_RCVD_IN_ZEN RBL: Received via a relay in Spamhaus Zen
* [10.10.114.156 listed in zen.dnsbl]
The only place that IP can be found (i.e. cat spam-97InS+5ooirt | grep
10.10.114.156) is in the three headers above. The rcvd lines do not match.
YOu're rule sort of dangerous as it may list PBL stuff on non
last-external, etc,
You're safest bet is to setup your recursor to forward all you spamhaus
queries to you local rblsnd instace and stick to the stock SA spamhaus
rules.
ITS_RCVD_IN_ZEN should be __ITS_RCVD_IN_ZEN and not be scored etc
(see 20_dnsbl_tests.cf for rule logic)
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On Wed, 14 Aug 2013 14:49:37 +0100 (BST) Nigel Smith gb10hkzo-...@yahoo.co.uk wrote: 30 ITS_RCVD_IN_ZEN RBL: Received via a relay in Spamhaus Zen [10.10.114.156 listed in zen.dnsbl] That's suspicious. 10.10.114.156 is an RFC-1918 private allocation address. There's no way it should be listed in a public DNSBL. Regards, David.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 08/14/2013 04:32 PM, David F. Skoll wrote: On Wed, 14 Aug 2013 14:49:37 +0100 (BST) Nigel Smith gb10hkzo-...@yahoo.co.uk wrote: 30 ITS_RCVD_IN_ZEN RBL: Received via a relay in Spamhaus Zen [10.10.114.156 listed in zen.dnsbl] That's suspicious. 10.10.114.156 is an RFC-1918 private allocation address. There's no way it should be listed in a public DNSBL. I have a hunch - would like to see Nigel's rbldnsd's conf. Nigel would you pls post this + all your spamhaus rules?
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On Wed, 14 Aug 2013, Kevin A. McGrail wrote: On 8/14/2013 9:49 AM, Nigel Smith wrote: This triggers : * 30 ITS_RCVD_IN_ZEN RBL: Received via a relay in Spamhaus Zen * [10.10.114.156 listed in zen.dnsbl] 10.X is a private network. Why is Zen listing it? A better question is: why is the RBL check code even querying about an RFC1918 address at all? I can't think of any use case where that would be valid behavior. I'd suggest this is worthy of a bugzilla entry. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Homeland Security: Specializing in Tactical Band-aids for Strategic Problems. -- Eric K. in Bruce Schneier's blog --- Tomorrow: the 68th anniversary of the end of World War II
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
10.X is a private network. Why is Zen listing it ? Becasuse I masked the first two octets to protect the innocent. ;-) Have you checked that IP on the real Zen listing and not on your cached server? Yes, I have checked on the real Zen lists and the real IP is there.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 08/14/2013 04:51 PM, John Hardin wrote: On Wed, 14 Aug 2013, Kevin A. McGrail wrote: On 8/14/2013 9:49 AM, Nigel Smith wrote: This triggers : * 30 ITS_RCVD_IN_ZEN RBL: Received via a relay in Spamhaus Zen * [10.10.114.156 listed in zen.dnsbl] 10.X is a private network. Why is Zen listing it? A better question is: why is the RBL check code even querying about an RFC1918 address at all? I can't think of any use case where that would be valid behavior. I'd suggest this is worthy of a bugzilla entry. If he borked his rbldnsd config badly, it could be possible.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On Wed, 14 Aug 2013 07:51:14 -0700 (PDT) John Hardin jhar...@impsec.org wrote: A better question is: why is the RBL check code even querying about an RFC1918 address at all? I can't think of any use case where that would be valid behavior. I'd suggest this is worthy of a bugzilla entry. I can think of only one case and it's contrived: In unit- or regression-test suites. I agree that RBL lookups by default should skip bogus addresses like RFC1918 and multicast addresses, but there should be a way to override this for test purposes. Regards, David.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Hi Kevin (and the entire list), Many many many apologies for not making it clear that I masked the affected IP. I don't really want to post it in public for all and sundry. Happy to give people the REAL headers off-list. Nigel
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 08/14/2013 04:51 PM, Nigel Smith wrote: 10.X is a private network. Why is Zen listing it ? Becasuse I masked the first two octets to protect the innocent. ;-) Have you checked that IP on the real Zen listing and not on your cached server? Yes, I have checked on the real Zen lists and the real IP is there. How did you check this? grep? I just grepped thru all spamhaus zones and nothing.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
YOu're rule sort of dangerous as it may list PBL stuff on non last-external, etc, Sort of dangerous ? It works beautifully for us ! Until the recent issues with Bigfish we've had zero false positives and many many many good catches ! I'm only following the guidelines at http://www.spamhaus.org/whitepapers/effective_filtering/ where they state The first stage is to install the Spamhaus Zen blocklist on your incoming mail relay(s). Zen, which is a combination of Spamhaus's SBL, XBL and PBL blocklists
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 14/08/2013 15:51, Nigel Smith wrote: 10.X is a private network. Why is Zen listing it ? Becasuse I masked the first two octets to protect the innocent. ;-) I wonder whether you should have chosen an RFC5737 address rather than an RFC1918 address for your obfuscation purposes... -- Regards, Giles Coochey, CCNP, CCNA, CCNAS NetSecSpec Ltd +44 (0) 8444 780677 +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk gi...@coochey.net smime.p7s Description: S/MIME Cryptographic Signature
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 8/14/2013 10:56 AM, Nigel Smith wrote: YOu're rule sort of dangerous as it may list PBL stuff on non last-external, etc, Sort of dangerous ? It works beautifully for us ! Until the recent issues with Bigfish we've had zero false positives and many many many good catches ! I'm only following the guidelines at http://www.spamhaus.org/whitepapers/effective_filtering/ where they state The first stage is to install the Spamhaus Zen http://www.spamhaus.org/zen/ blocklist on your incoming mail relay(s). Zen, which is a combination of Spamhaus's SBL, XBL and PBL blocklists Right ... On your incoming mail relays ... This is referring to using it as a blacklist for incoming connections where it is only checking the IP address of the system making the connection. If you use it in SA where it can check other IP addresses in the headers, it can be dangerous. Entries in the PBL should not be connecting directly to your server, however there is no problem with them being in the other received headers. -- Bowie
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
I wonder whether you should have chosen an RFC5737 address rather than an RFC1918 address for your obfuscation purposes... Because I forgot about RFC5737. ;-( As I said, happy to give full un-munged headers off-list.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On Wed, 14 Aug 2013, Axb wrote: On 08/14/2013 04:51 PM, John Hardin wrote: On Wed, 14 Aug 2013, Kevin A. McGrail wrote: On 8/14/2013 9:49 AM, Nigel Smith wrote: This triggers : * 30 ITS_RCVD_IN_ZEN RBL: Received via a relay in Spamhaus Zen * [10.10.114.156 listed in zen.dnsbl] 10.X is a private network. Why is Zen listing it? A better question is: why is the RBL check code even querying about an RFC1918 address at all? I can't think of any use case where that would be valid behavior. I'd suggest this is worthy of a bugzilla entry. If he borked his rbldnsd config badly, it could be possible. What does the rbldnsd config have to do with whether or not a RBL lookup on a RFC1918 address makes any sense? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Justice is justice, whereas social justice is code for one set of rules for the rich, another for the poor; one set for whites, another set for minorities; one set for straight men, another for women and gays. In short, it's the opposite of actual justice. -- Burt Prelutsky --- Tomorrow: the 68th anniversary of the end of World War II
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 08/14/2013 05:02 PM, Nigel Smith wrote: I wonder whether you should have chosen an RFC5737 address rather than an RFC1918 address for your obfuscation purposes... Because I forgot about RFC5737. ;-( As I said, happy to give full un-munged headers off-list. Nigel sent me the headers and the listed IP is NOT a private IP, but a legitimately PBL listing, a mobile ISP :) His problem is his homebrew single do it all SA rule which does deep header checks against PBL instead of last-external.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On Wed, 14 Aug 2013, Nigel Smith wrote: 10.X is a private network. Why is Zen listing it ? Becasuse I masked the first two octets to protect the innocent. ;-) That's a rotten idea when asking questions about RBLs... In this case, asking about X.X. would have been less confusing. Se we have two problems here: parsing IP addresses from inappropriate headers, and (potentially) the RBL code doing lookups of RFC1918 addresses. -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ jhar...@impsec.orgFALaholic #11174 pgpk -a jhar...@impsec.org key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- Justice is justice, whereas social justice is code for one set of rules for the rich, another for the poor; one set for whites, another set for minorities; one set for straight men, another for women and gays. In short, it's the opposite of actual justice. -- Burt Prelutsky --- Tomorrow: the 68th anniversary of the end of World War II
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 8/14/2013 10:19 AM, Kevin A. McGrail wrote: On 8/14/2013 10:14 AM, Jeremy McSpadden wrote: http://www.spamhaus.org/query/ip/10.10.114.156 * * * 10.10.114.156 is not listed in the SBL* *10.10.114.156 is not listed in the PBL* *10.10.114.156 is not listed in the XBL* Then I would say you have something in your DNS infrastructure that is returning FPs on your zen queries OR it has already been resolved by Spamhaus. If you query it manually through your DNS infrastructure what do you get? Whether the IP is listed in Zen or not is really beside the point. Why is this header even being checked against Zen? Shouldn't that be limited to the Received headers? -- Bowie
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 08/14/2013 05:08 PM, John Hardin wrote: On Wed, 14 Aug 2013, Axb wrote: On 08/14/2013 04:51 PM, John Hardin wrote: On Wed, 14 Aug 2013, Kevin A. McGrail wrote: On 8/14/2013 9:49 AM, Nigel Smith wrote: This triggers : * 30 ITS_RCVD_IN_ZEN RBL: Received via a relay in Spamhaus Zen * [10.10.114.156 listed in zen.dnsbl] 10.X is a private network. Why is Zen listing it? A better question is: why is the RBL check code even querying about an RFC1918 address at all? I can't think of any use case where that would be valid behavior. I'd suggest this is worthy of a bugzilla entry. If he borked his rbldnsd config badly, it could be possible. What does the rbldnsd config have to do with whether or not a RBL lookup on a RFC1918 address makes any sense? If you mix all zones into one generic, DBL's IP entries may get leaked into IP BLs - never tried such a thing, but i could imagine it happening.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
If he borked his rbldnsd config badly, it could be possible. Please guys, can we get this thread back on track. The RFC1918 send many of you off on the wrong tangent, I apologise for that profusely again. ;-)
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 08/14/2013 05:10 PM, Bowie Bailey wrote: On 8/14/2013 10:19 AM, Kevin A. McGrail wrote: On 8/14/2013 10:14 AM, Jeremy McSpadden wrote: http://www.spamhaus.org/query/ip/10.10.114.156 * * * 10.10.114.156 is not listed in the SBL* *10.10.114.156 is not listed in the PBL* *10.10.114.156 is not listed in the XBL* Then I would say you have something in your DNS infrastructure that is returning FPs on your zen queries OR it has already been resolved by Spamhaus. If you query it manually through your DNS infrastructure what do you get? Whether the IP is listed in Zen or not is really beside the point. Why is this header even being checked against Zen? Shouldn't that be limited to the Received headers? Guys,. the 10. IP is not listed - Nigel made that up and sent us thur a pointless chase. The listed IP is in the 166.147.64.0/18 range http://www.spamhaus.org/pbl/query/PBL679873
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
That's a rotten idea when asking questions about RBLs... In this case, asking about X.X. would have been less confusing. Yes, I'm sorry and I've already given myself 30 lashings ! ;-( Se we have two problems here: parsing IP addresses from inappropriate headers, and (potentially) the RBL code doing lookups of RFC1918 addresses. That's the point I'm trying to make here. SA is parsing from parts it should not be !! The whole Zen or no Zen thing that some others are going on about is not really relevant. SA should **NOT** be reading the parts it is !
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 8/14/2013 11:15 AM, Axb wrote: On 08/14/2013 05:10 PM, Bowie Bailey wrote: Whether the IP is listed in Zen or not is really beside the point. Why is this header even being checked against Zen? Shouldn't that be limited to the Received headers? Guys,. the 10. IP is not listed - Nigel made that up and sent us thur a pointless chase. The listed IP is in the 166.147.64.0/18 range http://www.spamhaus.org/pbl/query/PBL679873 Irrelevant. Why is an X-* header even being parsed for IPs? -- Bowie
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 8/14/2013 11:06 AM, Nigel Smith wrote: Right ... On your incoming mail relays ... If you use it in SA where it can check other IP addresses in the headers, it can be dangerous. If its such a big deal, why does __RCVD_IN_ZEN have a default score of 0 .. all I did was disable __RCVD_IN_ZEN and copy its exact rule to my local.cf, just amending the domain it queried. As far as I'm concerned I've done nothing wrong ? If its a big deal, why don't you guys trash the __RCVD_IN_ZEN rule ? __RCVD_IN_ZEN is a sub-rule and should not be scored at all. It is there so you can use it in metas. From the docs: Note that test names which begin with ’__’ are reserved for meta-match sub-rules, and are not scored or listed in the ’tests hit’ reports. -- Bowie
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Irrelevant. Why is an X-* header even being parsed for IPs? Agreed. That's what I came here to ask in the first place, even if I managed to make a right mess of even asking that ! ;-)
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 08/14/2013 05:15 PM, Nigel Smith wrote:
That's a rotten idea when asking questions about RBLs... In this
case, asking about X.X. would have been less confusing.
Yes, I'm sorry and I've already given myself 30 lashings ! ;-(
Se we have two problems here: parsing IP addresses from
inappropriate headers, and (potentially) the RBL code doing lookups
of RFC1918 addresses.
That's the point I'm trying to make here. SA is parsing from parts
it should not be !! The whole Zen or no Zen thing that some
others are going on about is not really relevant. SA should **NOT**
be reading the parts it is !
SA is doing it right - your rules are wrong.
pls try this - watch out for line MUA breaks!
header __ITS_RCVD_IN_ZENeval:check_rbl('zen', 'zen.dnsbl.')
describe __ITS_RCVD_IN_ZEN Received via a relay in Spamhaus Zen
tflags __ITS_RCVD_IN_ZENnet
reuse __ITS_RCVD_IN_ZEN
header ITS_RCVD_IN_SBL eval:check_rbl_sub('zen', '127.0.0.2')
describe ITS_RCVD_IN_SBLReceived via a relay in Spamhaus SBL
tflags ITS_RCVD_IN_SBL net
reuse ITS_RCVD_IN_SBL
# XBL is the Exploits Block List: http://www.spamhaus.org/xbl/
header ITS_RCVD_IN_XBL eval:check_rbl('zen-lastexternal', 'zen.dnsbl.',
'^127\.0\.0\.[45678]$')
describe ITS_RCVD_IN_XBLReceived via a relay in Spamhaus XBL
tflags ITS_RCVD_IN_XBL net
reuse ITS_RCVD_IN_XBL
# PBL is the Policy Block List: http://www.spamhaus.org/pbl/
header ITS_RCVD_IN_PBL eval:check_rbl('zen-lastexternal', 'zen.dnsbl.',
'^127\.0\.0\.1[01]$')
describe ITS_RCVD_IN_PBLReceived via a relay in Spamhaus PBL
tflags ITS_RCVD_IN_PBL net
reuse ITS_RCVD_IN_PBL
As I posted previously, the safer way to do it is to tell your recursor
to forward all spamhaus queries to you local rblsnd and NOT to tinker
with SA rules but then...
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 14/08/2013 16:02, Nigel Smith wrote: I wonder whether you should have chosen an RFC5737 address rather than an RFC1918 address for your obfuscation purposes... Because I forgot about RFC5737. ;-( As I said, happy to give full un-munged headers off-list. It's OK, I was just trying to be funny.:-) -- Regards, Giles Coochey, CCNP, CCNA, CCNAS NetSecSpec Ltd +44 (0) 8444 780677 +44 (0) 7983 877438 http://www.coochey.net http://www.netsecspec.co.uk gi...@coochey.net smime.p7s Description: S/MIME Cryptographic Signature
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Because some Webmail providers don't use a proper Received: header for the initial hop, but add an X-Originating-IP: header instead. Two things that bother me about that reply. First, SA *should* know about the major filtering providers (Bigfish, Postini etc.) and be able to deal with them accordingly. Second, X-Originating-IP, as in the IP address of the end-user terminal that's logged into webmail ? What's the point of parsing that ?
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Why is an X-* header even being parsed for IPs? Because some Webmail providers don't use a proper Received: header for the initial hop, but add an X-Originating-IP: header instead. Regards, David.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On Wed, 14 Aug 2013 16:28:45 +0100 (BST) Nigel Smith gb10hkzo-...@yahoo.co.uk wrote: Two things that bother me about that reply. First, SA *should* know about the major filtering providers (Bigfish, Postini etc.) and be able to deal with them accordingly. OK. Second, X-Originating-IP, as in the IP address of the end-user terminal that's logged into webmail ? What's the point of parsing that ? A couple of use-cases come to mind: 1) An RBL of known-compromised machines on (mostly-)static cable ISP addresses makes sense. 2) You might want to geolocate the originating IP for various purposes. For example, I'm very unlikely to receive ham from people located in China, the Ukraine, Uzbekistan, etc... Regards, David.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 08/14/2013 05:28 PM, Nigel Smith wrote: Because some Webmail providers don't use a proper Received: header for the initial hop, but add an X-Originating-IP: header instead. Two things that bother me about that reply. First, SA *should* know about the major filtering providers (Bigfish, Postini etc.) and be able to deal with them accordingly. SA does it right - see last-external for the different lookup types. SA knows nothing about IPs. it only knows about what to lookup and the BL config works correctly when rules are correct. If you decide to break the logic an do deep header checks on the wrong BL then your stuck. Second, X-Originating-IP, as in the IP address of the end-user terminal that's logged into webmail ? What's the point of parsing that ? African 419 sender thankfully detected by Spamcop?
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 08/14/2013 05:31 PM, Nigel Smith wrote:
Actually Axb, these are my current rules, so I might not be as wrong
as you think..
# ITS Local
header ITS_RCVD_IN_ZENeval:check_rbl('zen', 'zen.dnsbl.')
describe ITS_RCVD_IN_ZEN Received via a relay in Spamhaus Zen
tflags ITS_RCVD_IN_ZENnet
reuse ITS_RCVD_IN_ZEN
scoreITS_RCVD_IN_ZEN30.0
THIS rules is wrong!
see the difference to what i posted and Bowie's comment
you DON'T want deep header check on all of ZEN
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 8/14/2013 11:31 AM, Nigel Smith wrote:
Actually Axb, these are my current rules, so I might not be as wrong
as you think..
# ITS Local
header ITS_RCVD_IN_ZENeval:check_rbl('zen', 'zen.dnsbl.')
describe ITS_RCVD_IN_ZEN Received via a relay in Spamhaus Zen
tflags ITS_RCVD_IN_ZENnet
reuse ITS_RCVD_IN_ZEN
scoreITS_RCVD_IN_ZEN30.0
This should not be scored at all. Just use the others instead. The
only things you'll catch with this vs the separate rules below are false
positives. You can either change this to __ITS_RCVD_IN_ZEN, or set the
score to 0.001.
#
header ITS_RCVD_IN_SBL eval:check_rbl_sub('zen',
'^127\.0\.0\.[23]$')
describe ITS_RCVD_IN_SBLReceived via a relay in Spamhaus SBL
tflags ITS_RCVD_IN_SBL net
reuse ITS_RCVD_IN_SBL
scoreITS_RCVD_IN_SBL30.0
#
header ITS_RCVD_IN_XBL eval:check_rbl('zen-lastexternal',
'zen.dnsbl.', '^127\.0\.0\.[4567]$')
describe ITS_RCVD_IN_XBLReceived via a relay in Spamhaus XBL
tflags ITS_RCVD_IN_XBL net
reuse ITS_RCVD_IN_XBL
scoreITS_RCVD_IN_XBL30.0
#
header ITS_RCVD_IN_PBL eval:check_rbl('zen-lastexternal',
'zen.dnsbl.', '^127\.0\.0\.1[01]$')
describe ITS_RCVD_IN_PBLReceived via a relay in Spamhaus PBL
tflags ITS_RCVD_IN_PBL net
reuse ITS_RCVD_IN_PBL ITS_RCVD_IN_PBL
T_RCVD_IN_PBL_WITH_NJABL_DUL RCVD_IN_NJABL_DUL
scoreITS_RCVD_IN_PBL30.0
#
uridnssub ITS_URIBL_SBLzen.dnsbl. A 127.0.0.2
body ITS_URIBL_SBLeval:check_uridnsbl('ITS_URIBL_SBL')
describe ITS_URIBL_SBLContains an URL listed in the SBL blocklist
tflags ITS_URIBL_SBLnet
reuse ITS_URIBL_SBL
scoreITS_URIBL_SBL30.0
#
# DBL, http://www.spamhaus.org/dbl/
if can(Mail::SpamAssassin::Plugin::URIDNSBL::has_tflags_domains_only)
urirhssub ITS_URIBL_DBL_SPAM dbl.dnsbl. A 127.0.1.2
body ITS_URIBL_DBL_SPAM eval:check_uridnsbl('ITS_URIBL_DBL_SPAM')
describe ITS_URIBL_DBL_SPAM Contains an URL listed in the DBL blocklist
tflags ITS_URIBL_DBL_SPAM net domains_only
scoreITS_URIBL_DBL_SPAM 30.0
# this indicates that IP-address queries were sent to DBL, and should
# never appear; if it does, something is wrong with SpamAssassin
urirhssub ITS_URIBL_DBL_ERROR dbl.dnsbl. A 127.0.1.255
body ITS_URIBL_DBL_ERROR eval:check_uridnsbl('ITS_URIBL_DBL_ERROR')
describe ITS_URIBL_DBL_ERROR Error: queried the DBL blocklist for an IP
tflags ITS_URIBL_DBL_ERROR net domains_only
endif
#
The rest should be fine.
--
Bowie
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Actually Axb, these are my current rules, so I might not be as wrong as you
think..
# ITS Local
header ITS_RCVD_IN_ZEN eval:check_rbl('zen', 'zen.dnsbl.')
describe ITS_RCVD_IN_ZEN Received via a relay in Spamhaus Zen
tflags ITS_RCVD_IN_ZEN net
reuse ITS_RCVD_IN_ZEN
scoreITS_RCVD_IN_ZEN30.0
#
header ITS_RCVD_IN_SBL eval:check_rbl_sub('zen',
'^127\.0\.0\.[23]$')
describe ITS_RCVD_IN_SBL Received via a relay in Spamhaus SBL
tflags ITS_RCVD_IN_SBL net
reuse ITS_RCVD_IN_SBL
scoreITS_RCVD_IN_SBL30.0
#
header ITS_RCVD_IN_XBL eval:check_rbl('zen-lastexternal',
'zen.dnsbl.', '^127\.0\.0\.[4567]$')
describe ITS_RCVD_IN_XBL Received via a relay in Spamhaus XBL
tflags ITS_RCVD_IN_XBL net
reuse ITS_RCVD_IN_XBL
scoreITS_RCVD_IN_XBL30.0
#
header ITS_RCVD_IN_PBL eval:check_rbl('zen-lastexternal',
'zen.dnsbl.', '^127\.0\.0\.1[01]$')
describe ITS_RCVD_IN_PBL Received via a relay in Spamhaus PBL
tflags ITS_RCVD_IN_PBL net
reuse ITS_RCVD_IN_PBL ITS_RCVD_IN_PBL
T_RCVD_IN_PBL_WITH_NJABL_DUL RCVD_IN_NJABL_DUL
scoreITS_RCVD_IN_PBL30.0
#
uridnssub ITS_URIBL_SBL zen.dnsbl. A 127.0.0.2
body ITS_URIBL_SBL eval:check_uridnsbl('ITS_URIBL_SBL')
describe ITS_URIBL_SBL Contains an URL listed in the SBL blocklist
tflags ITS_URIBL_SBL net
reuse ITS_URIBL_SBL
scoreITS_URIBL_SBL30.0
#
# DBL, http://www.spamhaus.org/dbl/
if can(Mail::SpamAssassin::Plugin::URIDNSBL::has_tflags_domains_only)
urirhssub ITS_URIBL_DBL_SPAM dbl.dnsbl. A 127.0.1.2
body ITS_URIBL_DBL_SPAM eval:check_uridnsbl('ITS_URIBL_DBL_SPAM')
describe ITS_URIBL_DBL_SPAM Contains an URL listed in the DBL blocklist
tflags ITS_URIBL_DBL_SPAM net domains_only
scoreITS_URIBL_DBL_SPAM 30.0
# this indicates that IP-address queries were sent to DBL, and should
# never appear; if it does, something is wrong with SpamAssassin
urirhssub ITS_URIBL_DBL_ERROR dbl.dnsbl. A 127.0.1.255
body ITS_URIBL_DBL_ERROR eval:check_uridnsbl('ITS_URIBL_DBL_ERROR')
describe ITS_URIBL_DBL_ERROR Error: queried the DBL blocklist for an IP
tflags ITS_URIBL_DBL_ERROR net domains_only
endif
#
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 8/14/2013 11:25 AM, Axb wrote:
On 08/14/2013 05:15 PM, Nigel Smith wrote:
That's the point I'm trying to make here. SA is parsing from parts
it should not be !! The whole Zen or no Zen thing that some
others are going on about is not really relevant. SA should **NOT**
be reading the parts it is !
SA is doing it right - your rules are wrong.
pls try this - watch out for line MUA breaks!
header __ITS_RCVD_IN_ZENeval:check_rbl('zen', 'zen.dnsbl.')
describe __ITS_RCVD_IN_ZEN Received via a relay in Spamhaus Zen
tflags __ITS_RCVD_IN_ZENnet
reuse __ITS_RCVD_IN_ZEN
header ITS_RCVD_IN_SBL eval:check_rbl_sub('zen', '127.0.0.2')
describe ITS_RCVD_IN_SBLReceived via a relay in Spamhaus SBL
tflags ITS_RCVD_IN_SBL net
reuse ITS_RCVD_IN_SBL
# XBL is the Exploits Block List: http://www.spamhaus.org/xbl/
header ITS_RCVD_IN_XBL eval:check_rbl('zen-lastexternal', 'zen.dnsbl.',
'^127\.0\.0\.[45678]$')
describe ITS_RCVD_IN_XBLReceived via a relay in Spamhaus XBL
tflags ITS_RCVD_IN_XBL net
reuse ITS_RCVD_IN_XBL
# PBL is the Policy Block List: http://www.spamhaus.org/pbl/
header ITS_RCVD_IN_PBL eval:check_rbl('zen-lastexternal', 'zen.dnsbl.',
'^127\.0\.0\.1[01]$')
describe ITS_RCVD_IN_PBLReceived via a relay in Spamhaus PBL
tflags ITS_RCVD_IN_PBL net
reuse ITS_RCVD_IN_PBL
As I posted previously, the safer way to do it is to tell your recursor
to forward all spamhaus queries to you local rblsnd and NOT to tinker
with SA rules but then...
What I do is have my MTA reject connections based on Zen. This way, SA
doesn't even have to look at those messages. Much simpler and cleaner.
--
Bowie
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
As I posted previously, the safer way to do it is to tell your recursor
to forward all spamhaus queries to you local rblsnd and NOT to tinker
with SA rules but then...
My local recursor does forward to rbldnsd, as per their instructions...
zone dnsbl {
type forward;
forward only;
forwarders {
XXX port 10099;
};
};
Just checked the documentation Spamhaus provide. they suggest the following
in the local.cf.. which is very similar to what I've been doing, is it not
? (admittedly the below was not in the documentation a the time, so my
local.cf additions were home-brew).
header __RCVD_IN_ZEN eval:check_rbl('zen','zen.dnsbl.') header RCVD_IN_XBL
eval:check_rbl('zen-lastexternal', 'zen.dnsbl.','127.0.0.[45678]') header
RCVD_IN_PBL eval:check_rbl('zen-lastexternal', 'zen.dnsbl.', '127.0.0.1[01]')
uridnssub URIBL_SBL zen.dnsbl. A 127.0.0.2 urirhssub URIBL_DBL_SPAM
dbl.dnsbl. A 127.0.1.2 urirhssub URIBL_DBL_REDIR dbl.dnsbl. A 127.0.1.3
urirhssub URIBL_DBL_ERROR dbl.dnsbl. A 127.0.1.255
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 08/14/2013 05:41 PM, Nigel Smith wrote:
As I posted previously, the safer way to do it is to tell your recursor
to forward all spamhaus queries to you local rblsnd and NOT to tinker
with SA rules but then...
My local recursor does forward to rbldnsd, as per their instructions...
zone dnsbl {
type forward;
forward only;
forwarders {
XXX port 10099;
};
};
Just checked the documentation Spamhaus provide. they suggest the following
in the local.cf.. which is very similar to what I've been doing, is it not
? (admittedly the below was not in the documentation a the time, so my
local.cf additions were home-brew).
header __RCVD_IN_ZEN eval:check_rbl('zen','zen.dnsbl.') header RCVD_IN_XBL
eval:check_rbl('zen-lastexternal', 'zen.dnsbl.','127.0.0.[45678]') header
RCVD_IN_PBL eval:check_rbl('zen-lastexternal', 'zen.dnsbl.', '127.0.0.1[01]')
uridnssub URIBL_SBL zen.dnsbl. A 127.0.0.2 urirhssub URIBL_DBL_SPAM
dbl.dnsbl. A 127.0.1.2 urirhssub URIBL_DBL_REDIR dbl.dnsbl. A 127.0.1.3
urirhssub URIBL_DBL_ERROR dbl.dnsbl. A 127.0.1.255
I'm not a bind user/expert but (somebody pls verify this), to run
without having to change SA rules this should looks like:
(I use PDNS)
zone zen.spamhaus.org {
type forward;
forward only;
forwarders {
XXX port 10099;
};
zone sbl.spamhaus.org {
type forward;
forward only;
forwarders {
XXX port 10099;
};
zone xbl.spamhaus.org {
type forward;
forward only;
forwarders {
XXX port 10099;
};
zone sbl-xbl.spamhaus.org {
type forward;
forward only;
forwarders {
XXX port 10099;
};
zone dbl.spamhaus.org {
type forward;
forward only;
forwarders {
XXX port 10099;
};
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 08/14/2013 05:31 PM, Nigel Smith wrote:
Actually Axb, these are my current rules, so I might not be as wrong
as you think..
# ITS Local
header ITS_RCVD_IN_ZEN eval:check_rbl('zen', 'zen.dnsbl.')
describe ITS_RCVD_IN_ZEN Received via a relay in Spamhaus Zen
tflags ITS_RCVD_IN_ZEN net
reuse ITS_RCVD_IN_ZEN
scoreITS_RCVD_IN_ZEN30.0
THIS rules is wrong!
see the difference to what i posted and Bowie's comment
you DON'T want deep header check on all of ZEN
Well, I guess that's a fairly convincing argument. ;-)
I'll roll out fresh configs this evening and see how things go.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
On 8/14/2013 11:41 AM, Nigel Smith wrote:
As I posted previously, the safer way to do it is to tell your recursor
to forward all spamhaus queries to you local rblsnd and NOT to tinker
with SA rules but then...
My local recursor does forward to rbldnsd, as per their instructions...
zone dnsbl {
type forward;
forward only;
forwarders {
XXX port 10099;
};
};
Just checked the documentation Spamhaus provide. they suggest the
following in the local.cf.. which is very similar to what I've
been doing, is it not ? (admittedly the below was not in the
documentation a the time, so my local.cf additions were home-brew).
header __RCVD_IN_ZEN eval:check_rbl('zen','zen.dnsbl.')
header RCVD_IN_XBL eval:check_rbl('zen-lastexternal',
'zen.dnsbl.','127.0.0.[45678]')
header RCVD_IN_PBL eval:check_rbl('zen-lastexternal', 'zen.dnsbl.',
'127.0.0.1[01]')
uridnssub URIBL_SBL zen.dnsbl. A 127.0.0.2
urirhssub URIBL_DBL_SPAM dbl.dnsbl. A 127.0.1.2
urirhssub URIBL_DBL_REDIR dbl.dnsbl. A 127.0.1.3
urirhssub URIBL_DBL_ERROR dbl.dnsbl. A 127.0.1.255
Close, but if you notice, the check on the full Zen bl at the top is an
unscored sub-rule, while you were scoring 30 points for your version.
--
Bowie
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Close, but if you notice, the check on the full Zen bl at the top is an unscored sub-rule, while you were scoring 30 points for your version. Well, I guess my rules needed updating anyway. Spamhaus rolled out two new response codes I was not checking for ! Looking forward to seeing the change in mailflows once the changes go through. Thanks all for your help.
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Nigel Smith wrote:
On 08/14/2013 05:31 PM, Nigel Smith wrote:
Actually Axb, these are my current rules, so I might not be as wrong
as you think..
# ITS Local
header ITS_RCVD_IN_ZENeval:check_rbl('zen', 'zen.dnsbl.')
describe ITS_RCVD_IN_ZEN Received via a relay in Spamhaus Zen
tflags ITS_RCVD_IN_ZENnet
reuse ITS_RCVD_IN_ZEN
scoreITS_RCVD_IN_ZEN30.0
THIS rules is wrong!
see the difference to what i posted and Bowie's comment
you DON'T want deep header check on all of ZEN
Well, I guess that's a fairly convincing argument. ;-)
I'll roll out fresh configs this evening and see how things go.
The other thing that may cause issues down the road is accidentally
checking both your local datafeed copy *and* the public-DNS Spamhaus
data, because you've added new rules for your datafeed lookup with
different names than the stock rules.
When we switched to a datafeed subscription here, I just took the stock
rules and placed them (with the change of DNS zone name as necessary) in
my local rules without renaming them, so that they overwrote the stock
rule definitions. This made sure that we really were using the datafeed
data in our rbldnsd instances instead of the public DNS data.
-kgd
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Bowie Bailey wrote: What I do is have my MTA reject connections based on Zen. This way, SA doesn't even have to look at those messages. Much simpler and cleaner. It may still be reasonable to do the lookups for the SBL sublist - this one is OK to use for deep header scans, since they're (almost all) IP addresses or ranges owned or stolen by hard-core spammers. How reasonable is up to your local policy. And it's also useful for those users who insist on hosting their domain mail somewhere else, and forward mail to their account on your mail system. Your MTA lookup won't block spam on that path via Spamhaus lookup - but it's quite reasonable to bump the score to make sure any hits get tagged. -kgd
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
John Hardin skrev den 2013-08-14 17:08: If he borked his rbldnsd config badly, it could be possible. What does the rbldnsd config have to do with whether or not a RBL lookup on a RFC1918 address makes any sense? on the other hand would we like to see spams from rfc1918 sent out undetected, if the mailhost use lan for there custommers ?, it would imho be counter productive to not test rfc1918, just that there is no rfc1918 ip blacklists is another thing :=) well here i use: clear_internal_networks clear_trusted_networks clear_msa_networks internal_networks 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 trusted_networks 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 internal_networks 169.254.0.0/16 trusted_networks 169.254.0.0/16 some isps that have users on mobilebroadband use rfc1918 ips, sad but true, well if it will be hardcoded like 127.0.0.1 then ok with me
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Bowie Bailey skrev den 2013-08-14 17:18: Why is an X-* header even being parsed for IPs? in hope the ips is whitelisted ?
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Nigel Smith skrev den 2013-08-14 17:28: Because some Webmail providers don't use a proper Received: header for the initial hop, but add an X-Originating-IP: header instead. Two things that bother me about that reply. First, SA *should* know about the major filtering providers (Bigfish, Postini etc.) and be able to deal with them accordingly. Second, X-Originating-IP, as in the IP address of the end-user terminal that's logged into webmail ? What's the point of parsing that ? its same as testing spamhuas pbl with smtp auth clients, postfix does permit auth users before rbl testing, it would be incorrect to test auth users after rbl testing exp with pbl spamassassin can remove the test for x- headers if one want it
Re: Big problems with senders who use Microsoft Bigfish (a.k.a. FrontBridge)
Yes, I have checked on the real Zen lists and the real IP is there. Then your checking software is broken. None of the Spamhaus lists ever include anything in 10/8. R's, John
