Problematic Results of Mailspike Rules RCVD_IN_MSPIKE_Lx
We today received multiple requests from customers why legitimate Mails are suddenly marked as Spam. After checking individual Mails the reason where all the same: Mailspike is blocking the IP 81.169.146.176 (= mo-p04-ob.rzone.de), a heavy used Mailserver in Germany. This host is listed in dnswl.org and in our whitelist too - if using these whitelists no Mail would be blocked by the Mailspike Blacklist Entry. But: All Mails that comes in from this IP in SpamAssassing get a score of 4.0 because in SA the Score of RCVD_IN_MSPIKE_L4 gives such a high negative score - that is Nonsense in my Opinion. We just decided to locally reduce these MSPIKE_Lx SA Scores to zero. Why are the Mailspike Rules scored so much more than the similar Spamcop Rule RCVD_IN_BL_SPAMCOP_NET ?
A way to score Number of Recipients in the To: Line ?
I'm searching a way to give some extra Score depending on the Number of Recipients in the To: Headerline. In the last days there are massive Spamruns that are not marked as Spam - but all of them have a lot of Recipient Mail-Adresses in the To-Line (the last one more than 50..). I didn't found any Rule that does this. Anyone knows a solution ? Lutz Petersen
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: RCVD_IN_DNSWL_HI false negatives (solved)
Yust to your information: The configuration requested by Darxus (and others) with the 'trusted_networks' for the ip's listed in http://dnswl.org/s?s=20763 now works as it should. Means, no additional HI negatives scores for mails that were received by *.mobile.de and then forwarded.
Re: RCVD_IN_DNSWL_HI false negatives
I can see no reports about *.mobile.de The problem are _not_ mails from mobile.de (an ebay company) themselve. There is no spam from this host and in that way the whitelisting is ok. The problem is - you can create an email address ab...@mobile.de and let forward those mails to another addresses. All those mails also get the dnswl whitelist score.
Re: RCVD_IN_DNSWL_HI false negatives
Seems misunderstanding. Better I give you a real example (shortend to be readably and anonymous): Return-Path: wirtschaftswo...@derborse-fur-dummies.net * -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust * [194.50.69.1 listed in list.dnswl.org] * 1.7 URIBL_DBL_SPAM Contains an URL listed in the DBL blocklist * [URIs: thebinarysistema.com] * 1.0 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters * 2.0 FS_LARGE_PERCENT2 Larger than 100% in subj. * 1.1 DCC_CHECK Als Massen-E-Mail erkannt von DCC (dcc-servers.net) --- = 0.8 = No Spam Without the -5.0 DNSWL_HI it would have been tagged (correct) as spam with 5.8 Received: from unknown (HELO mail.mobile.de) (194.50.69.1) Received: from derborse-fur-dummies.net (derborse-fur-dummies.net [37.59.206.107]) by mail.mobile.de (Postfix) with ESMTP for spamvic...@mobile.de
Re: RCVD_IN_DNSWL_HI false negatives
Benny, even if we named equal - please read again, careful. * 1.7 URIBL_DBL_SPAM Contains an URL listed in the DBL blocklist * [URIs: thebinarysistema.com] this test is domain based That is no argument. Do you want to deactivate all SA rules that are not ip based ?? Received: from unknown (HELO mail.mobile.de) (194.50.69.1) unknown reverse dns ? No, simply means incoming mail from a host that has not authenticated. Received: from derborse-fur-dummies.net (derborse-fur-dummies.net [37.59.206.107]) by mail.mobile.de (Postfix) with ESMTP for spamvic...@mobile.de IP address 37.59.206.107 is not whitelisted at dnswl.org. should i repeat myself now ? :=) No, read again. 37.59.206.107 is listed in the Spamhaus SBL meanwhile.. Again: mail.mobile.de received a mail from a host that is listed in the SBL. Then forwarded this mail to an external address (our customer in this case). And suddenly this mail is not tagged as spam (as it would if mail were received directly) because of the -5.0 whitelist score in dnswl.
Re: RCVD_IN_DNSWL_HI false negatives
Received: from unknown (HELO mail.mobile.de) (194.50.69.1) Received: from derborse-fur-dummies.net (derborse-fur-dummies.net [37.59.206.107]) by mail.mobile.de (Postfix) with ESMTP for spamvic...@mobile.de by the way ,it looks like some newsletter, so your understanding of spam might not be shared public, so you should have evidence of definite spam content ( like viagra marketing etc ) delivered through mobile.de This is no newsletter - these guys are long term known hardcore spammers. That's the reason their ip is in the Spamhaus SBL (as a lot others too). if you use tag score upper 5 , 5.8 score is near point where false positive may happen ever In general you are right. But in this example case you can be sure this is 100% spam.
Re: RCVD_IN_DNSWL_HI false negatives (my solution)
Because this is a systematic problem _and_ I don't wan't to change the default SA scores for dnswl for some reasons seems the only way to fight against this special problem is to write a local rule. This rule should check if mail from mail.mobile.de has been originated by them itself (then it is never spam and the DNSWL_HI negative score is ok). But if mail is received from mail.mobile.de by external sources this negative score should be neutralized. It's a little bit hard to detect, but I'll archive some more examples to find a rule that will do this. It makes no sense to point this to dnswl - mobile.de itself is not a spam source itself.
Re: RCVD_IN_DNSWL_HI false negatives (my solution)
It has nothing to do with where the spam originates. Either the server relays spam or it doesn't. Who cares if it comes from the customers or some 3rd party? If mobile.de has bad filters, it should be downgraded to LOW or NONE until they are fixed. Henrik, you are right. I just made a report to dnswl for this case..
Re: RCVD_IN_DNSWL_HI false negatives (my solution)
If you use mobile.de as a forwarder, it may make sense to add there IPs to your trusted_networks configuration. If you do this, the DNSxL tests are applied to the IP _before_ the mobile.de hop. That is no problem special to us or our customers. The whitelist level for the four mobile.de IPs in the dnswl simply is wrong. Instead of HI a level of NONE would be right. It can't be the job of all SpamAssassin admins to write local rules because of such a wrong whitelist-scoring.
RCVD_IN_DNSWL_HI false negatives
Hi, we have real problems with SA spam scoring of some hosts that that are in list.dnswl.org with a hight trust level (RCVD_IN_DNSWL_HI). This in SA gives a negative score of -5.0. The description at the dnswl website says: Recommended Usage: Skip spam filtering for medium and high ranked IPs. These are trusted to send spam rarely enough that they are not worth filtering. But there are cases where this gives completely nonsense and let definitely spam mails all go through and become not spam-tagged. I'll give an example: Host 'mail.mobile.de'. This host (multiple ip) receives mail from external sources and forwards them to other mail-addresses. They seem to accept any mails from any ip, equal if dynamic ips or from known high level spam sources. I'll highly believe that they themselves never originate spam. But they forward mails from other sources that are 100% spam. Because mail.mobile.de is listed with DNSWL_HI all these mails get an dnswl negateive score of -5.0 - means that a lot of spam mails they forward get through with no Spam-tags. I don't wan't to generally reduce the scores of the RCVD_IN_DNSWL rules. But how to handle those cases? Obviously this listing gives a lot of 'false negatives'. The only way I see seems to manually neutral this -5.0 scoring for all forwarded mails with a local rule; but then all mails that are originated by themselves would become tagged as spam too. Does anyone have a solution for this ? Lutz Petersen
Re: spameatingmonkey.net down?
Thanks, just deleted this rules.. ;) We use this with really low scores - even if I can't remember of false positives (not more than most others). I don't believe their false rate reaches any of the others you mentioned (your bad note about spamcop I don't understand, within the last months they seem to be better as before).
Re: Scoring Yahoo mail from certain continents/countries ?
Maybe this would be something like that you want. It first checks the origin
country of an ip address (here limited to the 'well known' bad ones in africa).
The second step is a meta rule that first checks if mail comes from yahoo (both
webmail as smtp-login) and then look if the origin comes from one of these
countries. Not really checked a lot, but feel free to take it as an idea. Be
careful with the scores, otherwise all mails from those countries get hits in
spamassassin:
1) The origin country checks:
header __ORIGIN_COUNTRY
eval:check_rbl('origincountry-firsthop','zz.countries.nerd.dk.')
tflags __ORIGIN_COUNTRYnoautolearn
header ORIGIN_COUNTRY_BF
eval:check_rbl_sub('origincountry-firsthop', '^127\.0\.3\.86$')
describeORIGIN_COUNTRY_BF Origin in Burkina-Faso
tflags ORIGIN_COUNTRY_BF noautolearn
score ORIGIN_COUNTRY_BF 0.001
header ORIGIN_COUNTRY_BJ
eval:check_rbl_sub('origincountry-firsthop', '^127\.0\.0\.204$')
describeORIGIN_COUNTRY_BJ Origin in Benin
tflags ORIGIN_COUNTRY_BJ noautolearn
score ORIGIN_COUNTRY_BJ 0.001
header ORIGIN_COUNTRY_CI
eval:check_rbl_sub('origincountry-firsthop', '^127\.0\.1\.128$')
describeORIGIN_COUNTRY_CI Origin in Code-d-Ivoire
tflags ORIGIN_COUNTRY_CI noautolearn
score ORIGIN_COUNTRY_CI 0.001
header ORIGIN_COUNTRY_GA
eval:check_rbl_sub('origincountry-firsthop', '^127\.0\.1\.10$')
describeORIGIN_COUNTRY_GA Origin in Gabun
tflags ORIGIN_COUNTRY_GA noautolearn
score ORIGIN_COUNTRY_GA 0.001
header ORIGIN_COUNTRY_GH
eval:check_rbl_sub('origincountry-firsthop', '^127\.0\.1\.32$')
describeORIGIN_COUNTRY_GH Origin in Ghana
tflags ORIGIN_COUNTRY_GH noautolearn
score ORIGIN_COUNTRY_GH 0.001
header ORIGIN_COUNTRY_GM
eval:check_rbl_sub('origincountry-firsthop', '^127\.0\.1\.14$')
describeORIGIN_COUNTRY_GM Origin in Gambia
tflags ORIGIN_COUNTRY_GM noautolearn
score ORIGIN_COUNTRY_GM 0.001
header ORIGIN_COUNTRY_GN
eval:check_rbl_sub('origincountry-firsthop', '^127\.0\.1\.68$')
describeORIGIN_COUNTRY_GN Origin in Guinea
tflags ORIGIN_COUNTRY_GN noautolearn
score ORIGIN_COUNTRY_GN 0.001
header ORIGIN_COUNTRY_GW
eval:check_rbl_sub('origincountry-firsthop', '^127\.0\.2\.112$')
describeORIGIN_COUNTRY_GW Origin in Guinea-Bissao
tflags ORIGIN_COUNTRY_GW noautolearn
score ORIGIN_COUNTRY_GW 0.001
header ORIGIN_COUNTRY_NG
eval:check_rbl_sub('origincountry-firsthop', '^127\.0\.2\.54$')
describeORIGIN_COUNTRY_NG Origin in Nigeria
tflags ORIGIN_COUNTRY_NG noautolearn
score ORIGIN_COUNTRY_NG 0.001
header ORIGIN_COUNTRY_TG
eval:check_rbl_sub('origincountry-firsthop', '^127\.0\.3\.0$')
describeORIGIN_COUNTRY_TG Origin in Togo
tflags ORIGIN_COUNTRY_TG noautolearn
score ORIGIN_COUNTRY_TG 0.001
2) The yahoo check combined with some bad countries:
describe MY_YAHOO_BC Yahoo BadC
header__MY_YAHOO_HTTP X-Mailer =~ /YahooMailWebService/
header__MY_YAHOO_SMTP X-Yahoo-SMTP =~ /.*/
meta MY_YAHOO_BC (( __MY_YAHOO_HTTP + __MY_YAHOO_SMTP +
ORIGIN_COUNTRY_BF + ORIGIN_COUNTRY_BJ + ORIGIN_COUNTRY_CI + ORIGIN_COUNTRY_GH +
ORIGIN_COUNTRY_GM + ORIGIN_COUNTRY_GN + ORIGIN_COUNTRY_GW + ORIGIN_COUNTRY_LR +
ORIGIN_COUNTRY_NG + ORIGIN_COUNTRY_TG ) 1 )
tflagsMY_YAHOO_BC noautolearn
score MY_YAHOO_BC 5.001
Re: Scoring Yahoo mail from certain continents/countries ?
/^Received: from .41\..*web.*mail.*yahoo\.com via HTTP/i I admit this is rough albeit effective. On one side, not all Africa is 41. On the other side, I do not want to block all 41. It seems that the hardcore users only resists in a limited amount of netblocks, so it could make sense not to make one general rule but some of them, one for any of these netranges. Sometimes these (benin for example) are really small /23 etc. Only a small part from the home networks of our really good friends: 41.73.158.0/24 41-73-x.isghana 41.74.0.0/24 bj/no-rdns 41.79.216.0/22 bj/no-rdns 41.85.161.0/24 bj/no-rdns 41.85.162.0/23 bj/no-rdns 41.85.169.0/24 bj/no-rdns=benin-telecom-adsl-akpakpa 41.85.224.0/21 bj/no-rdns=benin-telecom-adsl-dowa 41.138.88.0/22 bj/no-rdns=etisalat 41.138.164.0/22ng/no-rdns=visafone 41.138.168.0/21ng/no-rdns=visafone 41.138.176.0/20ng/no-rdns=visafone 41.139.32.0/21 gh/no-rdns=avisonet 41.202.68.0/23 adsl-41.202.x.x.aviso.ci 41.202.88.0/21 adsl-41.202.x.x.aviso.ci 41.202.116.0/23host-41-202-x-x.afnet.net 41.203.67.0/24 ng/no-rdns 41.203.118.0/24ng/icsl-lagos
Re: How to report a spam botnet
It would likely be a good idea to block IP's in this list from using authenticated SMTP to relay not? Definitely not. We did so one week for testing. And had a lot of trouble with customers espacially using mobile/smartphones. Don't do this. This rbl does only make sense if you have different servers for receiving from external and for customer access. Then - only then - you this list makes sense on external receiving smtp servers, but never on hosts with authenticated customer access.
Re: no rDNS
Wondering about this detection: 2.4 RDNS_NONE Delivered to internal network by a host with no rDNS I saw this sometimes in mails delivered from external where people have sent their mail within an internal lan to for example the companies (internal reachable) mailserver. This rule seems to have excluded such cases, means not match when mail is send in cases like 192.168.0.0/16. Sorry, I have no example, have to look until I see this again..
HowTo Header-Report including match of rbl/rwl/etc. ?
Maybe this question is stupid, but I get a bloody nose on this.
If one have header reports activated mostly the header entries
looks like this:
* x.x SENDER_IN_GBUDB RBL: Sender listed in truncate.gbudb.net
* [199.239.233.233 listed in truncate.gbudb.net]
Now I have some local rules (against local dns lists) and in some
case they report the match in the second line, in some cases not.
I've studied a lot of other header entries and the spamassassin
code for the standard zone - but don't understand what I have to
do to get this second (informational) line. The rule looks like
this (name changed):
header DNS_FROM_IN_LOCAL_RHSBL eval:check_rbl_from_host('localrhsbl',
'rhsbl.local.')
describe DNS_FROM_IN_LOCAL_RHSBL Sender listed in rhsbl.local
tflags DNS_FROM_IN_LOCAL_RHSBL net
It's not wrong, this does his job. But - it does not contain this
second informational line. Any idea what I'm doing wrong ?
Re: Exclude from RCVD_IN_DNSWL_MED
It's not a special problem with messagelabs. It's in general a problem with all of these mass marketing mailers. In my opinion all of these companies/networks never should be placed in any whitelist. If they get blacklisted, so what? _They_ earn the money, manking has the pain. But - also in most cases it does not make sense to blacklist their ip-ranges. They distribute both senseful mailings as idiotic mails. The best way to do any kind of filtering will be such of the sender. Maintainers of blacklist should use ranges of thes mass marketing mailing companies to exclude listings in their blacklists; but they should never whitelist them too. Lutz Petersen
SA Sorbs Usage/Rules
I know some of the discussions in the past about usage of Sorbs RBLs
in Spamassassin. The scores today are as follows:
score RCVD_IN_SORBS_BLOCK 0 # n=0 n=1 n=2 n=3
score RCVD_IN_SORBS_DUL 0 0.001 0 0.001 # n=0 n=2
score RCVD_IN_SORBS_HTTP 0 2.499 0 0.001 # n=0 n=2
score RCVD_IN_SORBS_MISC 0 # n=0 n=1 n=2 n=3
score RCVD_IN_SORBS_SMTP 0 # n=0 n=1 n=2 n=3
score RCVD_IN_SORBS_SOCKS 0 2.443 0 1.927 # n=0 n=2
score RCVD_IN_SORBS_WEB 0 0.614 0 0.770 # n=0 n=2
score RCVD_IN_SORBS_ZOMBIE 0 # n=0 n=1 n=2 n=3
The 0-Scores for DUL was done because lot of people thought there
were too much false positives within that (I dont see so, but ok).
Another Argument for 0-Scoring or not using sorbs was that the rbl
contains a lot of old (meaning not actual) entries in the spam
section (in mind of the dislist policy). Ok.
But today I take a deeper look at the sorbs rbls and found, that
there is a very simple misconfigration in the SA rules. The rbl
check is done against the big 'dnsbl.sorbs.net' zone:
eval:check_rbl('sorbs', 'dnsbl.sorbs.net.')
And _that_ in my opinion is wrong. The rbl lookup should be done
against the rbl 'safe.dnsbl.sorbs.net' instead. This rbl is a
compilation of most of the sorbs partial lists as dnsbl.sorbs.net
but with a simple difference: In opposite to dnsl.sorbs.net it
does not contain the 'recent.spam' and the 'old.spam' partial
lists, which are contained in 'dnsbl.sorbs.net'. The only spam
listed in this 'safe.dnsbl.sorbs.net' contains spam of the last
24 hours, so the arguments against using sorbs especially because
of its spam delisting policy do not exist. One could simply change
the rbl lookup to the right zone and so also score spams within
that rbl (low).
Description of the different sorbs partial-zones as of the
aggregate zones here: https://www.sorbs.net/using.shtml
