ME Professional - latest version - I have added Spamhaus-Zen (zen.spamhaus.org) to the IP lookup (top section) of the DNS Blacklisting tab. The email was sent from my yahoo account and the following log shows it was rejected by Spamhaus-Zen.
12/28/08 09:44:53 ME-E0113: [1044] Message blocked: (98.136.44.42) was found in DNS blacklisted database Spamhaus-Zen.
If I check this IP directly on their website, it is not blocked anywhere by them.
Any ideas?
Thanks Paul
spamhaus-zen false positive
spamhaus-zen false positive
Just to clarify, when I have Spamhaus-Zen checking the IP addresses, *every* IP is flagged as spam.
Re: spamhaus-zen false positive
When Zen is used solely as the single test to block spam it could lead to false positives. The same applies to any single spam test. Zen includes the PBL which normally would cause false positives if emails are sent from IPs that are run off your your DSL lines,etcpsieloff wrote:ME Professional - latest version - I have added Spamhaus-Zen (zen.spamhaus.org) to the IP lookup (top section) of the DNS Blacklisting tab. The email was sent from my yahoo account and the following log shows it was rejected by Spamhaus-Zen.
12/28/08 09:44:53 ME-E0113: [1044] Message blocked: (98.136.44.42) was found in DNS blacklisted database Spamhaus-Zen.
If I check this IP directly on their website, it is not blocked anywhere by them.
Any ideas?
Thanks Paul
You can try reverting to the the sbl-xbl instead of Zen as this should reduce the false positives.
What we do is to use ZEN as a cumulative spam test and this works out very well
Cheers
MXSCAN :: AntiSpam & AntiVirus for MailEnable (now with Spamtrap/Honeypot!)
Built-in SpamAssassin, Clam, MessageSniffer, DNSBL, URLBL, DCC, Senderbase, SpamTrap, ShortCircuit, Content Filters, Disclamers, Archiving and more.
Visit www.mxuptime.com
Built-in SpamAssassin, Clam, MessageSniffer, DNSBL, URLBL, DCC, Senderbase, SpamTrap, ShortCircuit, Content Filters, Disclamers, Archiving and more.
Visit www.mxuptime.com
-
Monty_Python
- Posts: 45
- Joined: Sat Sep 13, 2008 7:51 pm
OK, a couple of piles of nonsense going on here. First of all that IP address has been clearly seen to be a source of spam - which is no great surprise. It's still listed on:
LISTED:98.136.44.42 ON no-more-funn.moensted.dk.
LISTED:68.142.255.16 ON no-more-funn.moensted.dk.
The last entry is that of NS2 for Yahoo - but I've never really rated 'no-more-fun'.
As IP addresses are added in real time IP's go on and off. Clearly if one of yahoo's mail servers is sending spam I want it blocked until the admin takes care of it. I don't care who the server belongs to, I want the spam blocked.
The anti-rbl brigade then pipe up how it's unreliable to block just on RBL. This is total rubbish. If a sender is genuine with the sending server set up properly, the 5xx SMTP error code will make that sender aware in the rare event of a false positive. The idea is to block likely spam at the earliest opportunity keeping wasted processing and network bandwidth at a minimum.
I don't think there is such a thing as a 'false positive' as far as RBL's go. IP addresses end up on RBL's for sending spam it's really that simple. With someone like yahoo it's fair to say they have a fight on their hands stopping spammers and adding their IP's will catch some genuine mail. This is all the more reason for them to be really on the ball with spam coming from their network. Imagine what a free for all it would be if RBL's did NOT block ranges belonging to people like Yahoo.
The only people who tend to bang on about RBL's being unreliable are either shisters trying to sell poor quality plug-ins that you don't need, spammers and the clueless.
Look at any big enterprise anti-spam solution and you'll find 'block on IP/RBL' at the top of the list everytime. If you don't like your mail server ending up on RBL's don't use a spam friendly mail server. Volia! Problem solved.
LISTED:98.136.44.42 ON no-more-funn.moensted.dk.
LISTED:68.142.255.16 ON no-more-funn.moensted.dk.
The last entry is that of NS2 for Yahoo - but I've never really rated 'no-more-fun'.
As IP addresses are added in real time IP's go on and off. Clearly if one of yahoo's mail servers is sending spam I want it blocked until the admin takes care of it. I don't care who the server belongs to, I want the spam blocked.
The anti-rbl brigade then pipe up how it's unreliable to block just on RBL. This is total rubbish. If a sender is genuine with the sending server set up properly, the 5xx SMTP error code will make that sender aware in the rare event of a false positive. The idea is to block likely spam at the earliest opportunity keeping wasted processing and network bandwidth at a minimum.
I don't think there is such a thing as a 'false positive' as far as RBL's go. IP addresses end up on RBL's for sending spam it's really that simple. With someone like yahoo it's fair to say they have a fight on their hands stopping spammers and adding their IP's will catch some genuine mail. This is all the more reason for them to be really on the ball with spam coming from their network. Imagine what a free for all it would be if RBL's did NOT block ranges belonging to people like Yahoo.
The only people who tend to bang on about RBL's being unreliable are either shisters trying to sell poor quality plug-ins that you don't need, spammers and the clueless.
Look at any big enterprise anti-spam solution and you'll find 'block on IP/RBL' at the top of the list everytime. If you don't like your mail server ending up on RBL's don't use a spam friendly mail server. Volia! Problem solved.
-
Monty_Python
- Posts: 45
- Joined: Sat Sep 13, 2008 7:51 pm
zen false positives
I have the zen.spamhaus.org rbl configured. My issue is that mail enable seems to be "deep header" checking the rbl. For example, when a user sends email to us from a Roadrunner (Time Warner Cable) connected computer, I can see from the logs that they are directly connecting from a legal mail server. However the email is rejected by mail enable with the end users IP address listed (not the mail server) as the cause for rejection. All Time Warner end users are included in the policy block list.
Normally, I would just stop using zen, and go back to sbl-xbl, however, sbl-xbl is supposedly going away in favor of zen. Is a setting that changes the behaviour of mail enable's RBL checking?
Normally, I would just stop using zen, and go back to sbl-xbl, however, sbl-xbl is supposedly going away in favor of zen. Is a setting that changes the behaviour of mail enable's RBL checking?
-
Monty_Python
- Posts: 45
- Joined: Sat Sep 13, 2008 7:51 pm
I see sooooo much spam from machines on Roadrunner I would consider that a blessing.
As for deep header scanning - I cannot say that I have seen that behaviour with Mail Enable out of the box. When I look at the DNS queries it makes it is only ever looking at the connecting IP in the header below;
Received: from mailenable.com ([209.213.99.115]) by xxxxx with MailEnable ESMTP; Tue, 31 Mar 2009 22:08:20 +0100
Are you using any other form of broken plugin with ME? Are you having some headers munged in between the client and the server?
As for deep header scanning - I cannot say that I have seen that behaviour with Mail Enable out of the box. When I look at the DNS queries it makes it is only ever looking at the connecting IP in the header below;
Received: from mailenable.com ([209.213.99.115]) by xxxxx with MailEnable ESMTP; Tue, 31 Mar 2009 22:08:20 +0100
Are you using any other form of broken plugin with ME? Are you having some headers munged in between the client and the server?
Honestly, I do consider it a blessing sometimes as well. Now if only I could get my users to understand that. ha. Try to explain to any user that it is the fault of the sending user. It almost never works...
I don't have any plugins running for ME (does antivirus count?).
I do have URI testing turned on as well, which scans links against the same service. I was under the impression that it would only test links in an href tag, not random IP addresses discovered in the header.
I don't have any plugins running for ME (does antivirus count?).
I do have URI testing turned on as well, which scans links against the same service. I was under the impression that it would only test links in an href tag, not random IP addresses discovered in the header.
-
Monty_Python
- Posts: 45
- Joined: Sat Sep 13, 2008 7:51 pm
I guess you are running a paid for version as opposed to standard then 
I can't speak for how that works and what it does. Deep header scanning is only logical if you are behind a forwarder/relay of some kind and all connetions appear from the same IP. Often the hops are spoofed and not to be trusted so there is little use in scanning them out.
I would think that if there is a setting in ME for deep header scanning or that forces that kind of behaviour - someone with that version will be along to point to it. If not and you find it, can you follow this post up?
I can't speak for how that works and what it does. Deep header scanning is only logical if you are behind a forwarder/relay of some kind and all connetions appear from the same IP. Often the hops are spoofed and not to be trusted so there is little use in scanning them out.
I would think that if there is a setting in ME for deep header scanning or that forces that kind of behaviour - someone with that version will be along to point to it. If not and you find it, can you follow this post up?
