Re: Rule to match a blacklist of email addresses.
On 10/01/2015 18:10, Reindl Harald wrote: I don't think I understand... Is this a strategy to allow me to reject emails to list-specific email addresses (in the absence of the expected List-Id header) - or something else? Uhm - no * Postfix adds the X-Local-Envelope-To header with the rcpt inside because parse out the envelope-rcpt from reveived headers is error prone and BCC mails don't contain To-Headers which would need to be parsed too because it contains not only the email * CUST_LESS_SPAM_TO contains a Regex for that header * if it matches 4.0 points are added to whatever result by other rules well, i generate such rules from a database with a webui I think that was an 'Uhm - yes - I didn't understand. I think I do now, thanks. :) I had anticipated that it would be harder to create rules to bounce based upon a combination of 'recipient' and List-ID - though I'd still love a recipe for that. I can easily add points where List-Id doesn't match recipient... but I can't see an easy way to generate a bounce without risking back scatter... and I don't want to risk that.
Re: Rule to match a blacklist of email addresses.
On 10/01/2015 18:10, Reindl Harald wrote: I don't think I understand... Is this a strategy to allow me to reject emails to list-specific email addresses (in the absence of the expected List-Id header) - or something else? Uhm - no * Postfix adds the X-Local-Envelope-To header with the rcpt inside because parse out the envelope-rcpt from reveived headers is error prone and BCC mails don't contain To-Headers which would need to be parsed too because it contains not only the email * CUST_LESS_SPAM_TO contains a Regex for that header * if it matches 4.0 points are added to whatever result by other rules well, i generate such rules from a database with a webui I think that was an 'Uhm - yes - I didn't understand. I think I do now, thanks. :) I had anticipated that it would be harder to create rules to bounce based upon a combination of 'recipient' and List-ID - though I'd still love a recipe for that. I can easily add points where List-Id doesn't match recipient... but I can't see an easy way to generate a bounce without risking back scatter... and I don't want to risk that.
Re: Malware Patrol SA Rules
W dniu 2015-01-11 o 04:49, Reindl Harald pisze: Am 10.01.2015 um 22:07 schrieb Marcin Mirosław: W dniu 2015-01-10 o 15:27, Reindl Harald pisze: Am 10.01.2015 um 15:19 schrieb David Flanigan: Is anyone using the Malware Patrol 3rd party Spamassassin Rules (https://www.malwarepatrol.net/index.shtml)? I have downloaded and looked them over and, in concept, they look pretty good. However the cf file is over 8.5megs (yes megs) in size. By far the biggest ruleset I have. I cannot think this would do good things for performance. Any experience, comments, etc? 8.5 MB SA rules is crazy that really belongs to clamav directly after SA because SA eats more http://sanesecurity.com/usage/signatures/ Imho clamav needs less CPU power than SA (and need less time to scane email) so I think it's better to use clamav before SA that is true *but* after a few months it turned out that ClamAV don't catch that much mail which was killed by the SA milter after it and so 90% of all messages need to pass both - for the overall system so it makes more sense to have SA in front I forgot about one, important thing, I'm using unofficial rules for Clamav. My stats counted since 2014-12 are: $ grep -r X-ACL-Warn: Virus found 201412* 201501*|wc -l 18314 $ find 201412* 2015* -type f|wc -l 33170 $ grep -hr X-ACL-Warn: Virus found 201412* 201501*|grep -c UNOFFICIAL 18288 $ grep -hr X-ACL-Warn: Virus found 201412* 201501*|grep -vc UNOFFICIAL 26 $ grep -hr X-ACL-Warn: Virus found 201412* 201501*|grep -v UNOFFICIAL|sort|uniq X-ACL-Warn: Virus found / znaleziono wirusa :Heuristics.Phishing.Email.SpoofedDomain X-ACL-Warn: Virus found / znaleziono wirusa :Heuristics.Safebrowsing.Suspected-malware_safebrowsing.clamav.net X-ACL-Warn: Virus found / znaleziono wirusa :Heuristics.Safebrowsing.Suspected-phishing_safebrowsing.clamav.net X-ACL-Warn: Virus found / znaleziono wirusa :Zip.Suspect.ExecutablePhoto-zippwd-2 $ grep -hr X-ACL-Warn: Virus found 201412* 201501*|grep UNOFFICIAL|grep -viE (Junk|url|Spam)|sort|uniq -c 1 X-ACL-Warn: Virus found / znaleziono wirusa :BofhlandMWFile1302.UNOFFICIAL 1 X-ACL-Warn: Virus found / znaleziono wirusa :BofhlandMWFile1306.UNOFFICIAL 7 X-ACL-Warn: Virus found / znaleziono wirusa :BofhlandMWFile1356.UNOFFICIAL 1 X-ACL-Warn: Virus found / znaleziono wirusa :Porcupine.Malware.29046.UNOFFICIAL 1 X-ACL-Warn: Virus found / znaleziono wirusa :Porcupine.Malware.29327.UNOFFICIAL 2 X-ACL-Warn: Virus found / znaleziono wirusa :Porcupine.Phishing.20003.UNOFFICIAL 724 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Foxhole.Zip_doc.UNOFFICIAL 715 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Foxhole.Zip_docx.UNOFFICIAL 94 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Foxhole.Zip_jpeg.UNOFFICIAL 970 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Foxhole.Zip_pdf.UNOFFICIAL 80 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Foxhole.Zip_xml.UNOFFICIAL 1 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Malware.19736.UNOFFICIAL 4 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Malware.21933.ZipHeur.UNOFFICIAL 1 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Malware.24212.ZipHeur.UNOFFICIAL 9 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Malware.24273.ZipHeur.UNOFFICIAL 2 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Malware.24306.UNOFFICIAL 1 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Malware.24423.ZipHeur.UNOFFICIAL 2 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Malware.24488.UNOFFICIAL 9 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Malware.24594.ZipHeur.UNOFFICIAL 15 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Malware.24595.ZipHeur.UNOFFICIAL 13 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Malware.24639.ZipHeur.UNOFFICIAL 2 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Malware.24646.DocHeur.UNOFFICIAL 9 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Malware.24647.ZipHeur.UNOFFICIAL 8 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Malware.24648.ZipHeur.UNOFFICIAL 5 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Malware.24675.XlsHeur.UNOFFICIAL 1 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Rogue.0hr.20141201-1850.UNOFFICIAL 11 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Rogue.0hr.20141202-0850.UNOFFICIAL 5 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Rogue.0hr.20141203-0953.UNOFFICIAL 11 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Rogue.0hr.20141208-0651.UNOFFICIAL 3 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Rogue.0hr.20141210-0848.UNOFFICIAL 26 X-ACL-Warn: Virus found / znaleziono wirusa :Sanesecurity.Rogue.0hr.20141212-1249.UNOFFICIAL 6
Re: possible bug in Mail::DKIM when keysize is under 1024 bits
On 1/10/2015 4:01 PM, Benny Pedersen wrote: opendkim have minimal keysize of 1024, else its considered invalid, so i am asking should Mail::DKIM follow this as valid or invalid even if the key check is PASS ? this leads to spamassassin VALID, but opendkim testing INVALID hmm A quick Google search brings up this https://wordtothewise.com/2012/11/how-long-is-your-dkim-key/ It's a recommendation not a requirement so the pass even when lower than 1024 is accurate. Regards, KAM
Re: Malware Patrol SA Rules
P.S.2. All grepping was made in directory contains only spam.
Re: Malware Patrol SA Rules
Am 11.01.2015 um 16:20 schrieb Marcin Mirosław: W dniu 2015-01-11 o 04:49, Reindl Harald pisze: Am 10.01.2015 um 22:07 schrieb Marcin Mirosław: W dniu 2015-01-10 o 15:27, Reindl Harald pisze: Am 10.01.2015 um 15:19 schrieb David Flanigan: Is anyone using the Malware Patrol 3rd party Spamassassin Rules (https://www.malwarepatrol.net/index.shtml)? I have downloaded and looked them over and, in concept, they look pretty good. However the cf file is over 8.5megs (yes megs) in size. By far the biggest ruleset I have. I cannot think this would do good things for performance. Any experience, comments, etc? 8.5 MB SA rules is crazy that really belongs to clamav directly after SA because SA eats more http://sanesecurity.com/usage/signatures/ Imho clamav needs less CPU power than SA (and need less time to scane email) so I think it's better to use clamav before SA that is true *but* after a few months it turned out that ClamAV don't catch that much mail which was killed by the SA milter after it and so 90% of all messages need to pass both - for the overall system so it makes more sense to have SA in front I forgot about one, important thing, I'm using unofficial rules for Clamav me too - but that did not change the numbers that sa-milter rejected a lot of more mails then clamav-milter before it over a longer time may also depend on the quality and scoring of bayes, we have 7500 ham and 7500 spam samples - handselected - and so a very high scoring while sa-milter rejects starting with 8.0 points, that's all backed by 11 different scored DNSWL, the scoring below is only healthy if you trust your bayes uncoditional! ifplugin Mail::SpamAssassin::Plugin::Bayes score BAYES_00 -3.5 score BAYES_05 -1.5 score BAYES_20 -0.5 score BAYES_40 -0.2 score BAYES_50 2.5 score BAYES_60 3.0 score BAYES_80 5.0 score BAYES_95 6.5 score BAYES_99 7.5 score BAYES_999 0.4 endif in summary the currently 24 DNSBL with different weights, backed by the 11 DNSWL, subject filters with different severity reach a 99.5% hitrate your number may vary, the milters / contetscanner are facing only 5% of all delivery attempts becaue the rest is eaten by RBL scoring [root@mail-gw:~]$ ls /var/lib/clamav/ total 179M -rw-r--r-- 1 clamupdate clamupdate 8.0K 2014-09-02 12:18 foxhole_all.cdb -rw-r--r-- 1 clamupdate clamupdate 1.9K 2014-09-19 12:34 foxhole_filename.cdb -rw-r--r-- 1 clamupdate clamupdate 39K 2014-09-02 12:18 foxhole_generic.cdb -rw-r--r-- 1 clamupdate clamupdate 357K 2015-01-05 20:55 bytecode.cld -rw-r--r-- 1 clamupdate clamupdate 80M 2015-01-11 19:25 daily.cld -rw-r--r-- 1 clamupdate clamupdate 62M 2014-11-30 22:28 main.cvd -rw-r--r-- 1 clamupdate clamupdate 104 2015-01-11 20:25 mirrors.dat -rw-r--r-- 1 clamupdate clamupdate 9.8K 2014-09-03 14:31 sanesecurity.ftm -rw-r--r-- 1 clamupdate clamupdate 77K 2015-01-11 19:48 bofhland_malware_attach.hdb -rw-r--r-- 1 clamupdate clamupdate 361K 2015-01-11 00:48 crdfam.clamav.hdb -rw-r--r-- 1 clamupdate clamupdate 19K 2015-01-11 17:52 rogue.hdb -rw-r--r-- 1 clamupdate clamupdate 1.6K 2014-11-21 15:51 spamattach.hdb -rw-r--r-- 1 clamupdate clamupdate 1.2K 2014-10-28 17:51 spamimg.hdb -rw-r--r-- 1 clamupdate clamupdate 74K 2015-01-11 19:45 winnow.attachments.hdb -rw-r--r-- 1 clamupdate clamupdate 254K 2015-01-11 19:45 winnow_bad_cw.hdb -rw-r--r-- 1 clamupdate clamupdate 266K 2015-01-11 19:45 winnow_extended_malware.hdb -rw-r--r-- 1 clamupdate clamupdate 213K 2015-01-11 19:45 winnow_malware.hdb -rw-r--r-- 1 clamupdate clamupdate 9.3K 2014-11-27 09:44 malwarehash.hsb -rw-r--r-- 1 clamupdate clamupdate 5.7K 2015-01-09 09:01 sigwhitelist.ign2 -rw-r--r-- 1 clamupdate clamupdate 21K 2015-01-06 11:53 spam.ldb -rw-r--r-- 1 clamupdate clamupdate 93K 2015-01-11 19:52 blurl.ndb -rw-r--r-- 1 clamupdate clamupdate 2.2M 2015-01-11 19:48 bofhland_cracked_URL.ndb -rw-r--r-- 1 clamupdate clamupdate 4.7K 2015-01-11 19:48 bofhland_malware_URL.ndb -rw-r--r-- 1 clamupdate clamupdate 5.4K 2015-01-11 19:48 bofhland_phishing_URL.ndb -rw-r--r-- 1 clamupdate clamupdate 5.9M 2015-01-03 16:04 junk.ndb -rw-r--r-- 1 clamupdate clamupdate 573K 2015-01-11 19:52 jurlbl.ndb -rw-r--r-- 1 clamupdate clamupdate 229K 2015-01-11 19:52 jurlbla.ndb -rw-r--r-- 1 clamupdate clamupdate 239K 2014-10-01 11:49 lott.ndb -rw-r--r-- 1 clamupdate clamupdate 3.6M 2015-01-09 19:14 phish.ndb -rw-r--r-- 1 clamupdate clamupdate 3.3M 2015-01-11 19:45 phishtank.ndb -rw-r--r-- 1 clamupdate clamupdate 1.8M 2015-01-06 16:51 scam.ndb -rw-r--r-- 1 clamupdate clamupdate 14M 2015-01-11 19:45 scamnailer.ndb -rw-r--r-- 1 clamupdate clamupdate 2.0M 2015-01-09 19:12 spear.ndb -rw-r--r-- 1 clamupdate clamupdate 64K 2015-01-11 19:52 spearl.ndb -rw-r--r-- 1 clamupdate clamupdate 937K 2015-01-11 19:45 winnow_malware_links.ndb -rw-r--r-- 1 clamupdate clamupdate 1.1M 2015-01-11 19:45 winnow_phish_complete_url.ndb -rw-r--r-- 1 clamupdate clamupdate 277K 2015-01-11 19:45 winnow_spam_complete.ndb
Re: possible bug in Mail::DKIM when keysize is under 1024 bits
On 1/11/2015 12:45 PM, Benny Pedersen wrote: Kevin A. McGrail skrev den 2015-01-11 18:16: A quick Google search brings up this https://wordtothewise.com/2012/11/how-long-is-your-dkim-key/ It's a recommendation not a requirement so the pass even when lower than 1024 is accurate. bug created, https://sourceforge.net/p/opendkim/bugs/215/ but i still think Mail::DKIM is at fault can spamassassin change to warn on small keysize ? It only warns the recipient who can do nothing about the issue really. Regards, KAM
Re: possible bug in Mail::DKIM when keysize is under 1024 bits
Am 11.01.2015 um 18:16 schrieb Kevin A. McGrail: On 1/10/2015 4:01 PM, Benny Pedersen wrote: opendkim have minimal keysize of 1024, else its considered invalid, so i am asking should Mail::DKIM follow this as valid or invalid even if the key check is PASS ? this leads to spamassassin VALID, but opendkim testing INVALID hmm A quick Google search brings up this https://wordtothewise.com/2012/11/how-long-is-your-dkim-key/ It's a recommendation not a requirement so the pass even when lower than 1024 is accurate. Regards, KAM however lets wait for error reports with keysize bigger then 1024, 2048 by so called smtp inspection features on some gateway and fireway products *g Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein
Re: possible bug in Mail::DKIM when keysize is under 1024 bits
Kevin A. McGrail skrev den 2015-01-11 18:16: A quick Google search brings up this https://wordtothewise.com/2012/11/how-long-is-your-dkim-key/ It's a recommendation not a requirement so the pass even when lower than 1024 is accurate. bug created, https://sourceforge.net/p/opendkim/bugs/215/ but i still think Mail::DKIM is at fault can spamassassin change to warn on small keysize ?
rule: virtual account not confirmed
Hello all, In some (apple|bank|creditcard) scam mail I found the following header and made a rule for it. X-Get-Message-Sender-Via: cpanel3.example.org: authenticated_id: f0829646/only user confirmed/virtual account not confirmed describe MJ_VACCOUNTvirtual account not confirmed header MJ_VACCOUNT X-Get-Message-Sender-Via =~ m;virtual account not confirmed; I scored it 1.5, I have no idea how to calculate a proper score, maybe someone cares to explain how to score? /MJ
Re: possible bug in Mail::DKIM when keysize is under 1024 bits
Kevin A. McGrail: https://wordtothewise.com/2012/11/how-long-is-your-dkim-key/ It's a recommendation not a requirement so the pass even when lower than 1024 is accurate. I disagree. Lauras article is more then two years old. But since more then 4 years ( Sep 2011 ) RFC 6376 say very clear: Signers MUST use RSA keys of at least 1024 bits ... ( https://tools.ietf.org/html/rfc6376#section-3.3.3 ) Andreas
Re: possible bug in Mail::DKIM when keysize is under 1024 bits
On Jan 11, 2015, at 3:40 PM, Kevin A. McGrail kmcgr...@pccc.com wrote: I disagree as well. You can't cherry pick your quotes and you are missing the long-lived caveat as well as the next sentence: Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits If it is 512 to 2048, I think the rfc is clear for recipients. Gmail and a few others have decided to behave like if there was no DKIM signature if the key 1024. Because today nearly anyone can crack a 512bits DKIM key and just for a few dollars. spamassassin could add positive points if the key 1024
Re: possible bug in Mail::DKIM when keysize is under 1024 bits
On 1/11/2015 10:04 PM, Franck Martin wrote: On Jan 11, 2015, at 3:40 PM, Kevin A. McGrail kmcgr...@pccc.com wrote: I disagree as well. You can't cherry pick your quotes and you are missing the long-lived caveat as well as the next sentence: Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits If it is 512 to 2048, I think the rfc is clear for recipients. Gmail and a few others have decided to behave like if there was no DKIM signature if the key 1024. Because today nearly anyone can crack a 512bits DKIM key and just for a few dollars. spamassassin could add positive points if the key 1024 I would likely accept and commit a patch that does if you want to work on the issue. regards, KAM
Re: possible bug in Mail::DKIM when keysize is under 1024 bits
I disagree as well. You can't cherry pick your quotes and you are missing the long-lived caveat as well as the next sentence: Verifiers MUST be able to validate signatures with keys ranging from 512 bits to 2048 bits If it is 512 to 2048, I think the rfc is clear for recipients. Regards, KAM On January 11, 2015 3:40:42 PM EST, A. Schulze s...@andreasschulze.de wrote: Kevin A. McGrail: https://wordtothewise.com/2012/11/how-long-is-your-dkim-key/ It's a recommendation not a requirement so the pass even when lower than 1024 is accurate. I disagree. Lauras article is more then two years old. But since more then 4 years ( Sep 2011 ) RFC 6376 say very clear: Signers MUST use RSA keys of at least 1024 bits ... ( https://tools.ietf.org/html/rfc6376#section-3.3.3 ) Andreas
Re: rule: virtual account not confirmed
On 1/11/2015 3:24 PM, Marieke Janssen wrote: Hello all, In some (apple|bank|creditcard) scam mail I found the following header and made a rule for it. X-Get-Message-Sender-Via: cpanel3.example.org: authenticated_id: f0829646/only user confirmed/virtual account not confirmed describe MJ_VACCOUNT virtual account not confirmed header MJ_VACCOUNT X-Get-Message-Sender-Via =~ m;virtual account not confirmed; I scored it 1.5, I have no idea how to calculate a proper score, maybe someone cares to explain how to score? There are two ways to generate scores: 1 - you can get a corpora of ham and spam and use analysis to identify an optimal score 2 - you can use experience (real world and/or guesstimates) to set a score. And to do #1, it's best to give it a starting point. Which means #2 is needed a bit anyway ;-) So my first step is ALWAYS to check my hand-sorted corporate for anecdotal signs that a rule will classify properly. We call this the S/O. See http://wiki.apache.org/spamassassin/S/O So if you have a rule that you think has a benefit to others, we can put it in a sandbox that then automatically tests it and promotes it if it looks good. This is the Rule QA system which is working but not reporting on the ruleqa website correctly. To get back to your question, the score for spam starts with a number based on how likely it is to misfire. And overall SA is designed as a framework to use LOTS of different rules with some that can misfire but hopefully still classify the email correctly. So I generally score a rule about 1.0 as a max. BUT I use meta rules a lot and based on the number of metas involve, I may consider each part of the meta allowing me to raise the score considerably. You can look at my KAM.cf for some guidance. In short, there are times and rules that benefit greatly from analysis and some that you just have to make a guess. More specifically, your rule above hits 11 items in my SPAM corpora but it also hit 10 in my Ham corpora including a user on the SA mailing list and another to the SA Board mailing list. This means it has an S/O which means it is worthless for classification because it has roughly equal hits in spam and ham. Sorry to say but I would recommend scrapping the rule. Regards, KAM
Permission Problem and bad file descriptor
Hello guys, Since yesterday I'm running a server with ubuntu 14.04.1 and spamassassin version 3.4.0-1ubuntu2. Spamassassin was installed as a package from the ubuntu repositories. SpamAssassin runs in daemon mode with a user named spamd. This morning I got the following email. It indicates, that there is something wrong with my permission settings. /etc/cron.daily/spamassassin: Jan 12 02:42:56.374 [23592] warn: config: path /var/lib/spamassassin/.spamassassin/user_prefs is inaccessible: Permission denied config: path /var/lib/spamassassin/.spamassassin/user_prefs is inaccessible: Permission denied cannot create a directory: Permission denied at /usr/share/perl5/Mail/SpamAssassin/Plugin/BodyRuleBaseExtractor.pm line 1034. cannot write to /var/lib/spamassassin/.spamassassin/sa-compile.cache/rules.body_0 at /usr/share/perl5/Mail/SpamAssassin/Plugin/BodyRuleBaseExtractor.pm line 1036. print() on closed filehandle CACHE at /usr/share/perl5/Mail/SpamAssassin/Plugin/BodyRuleBaseExtractor.pm line 1037. plugin: eval failed: error writing: Bad file descriptor at /usr/share/perl5/Mail/SpamAssassin/Plugin/BodyRuleBaseExtractor.pm line 1037. /var/lib/spamassassin/.spamassassin/user_prefs doesn't exist. The directory permissions are as follows: :~# ll -d /var/lib/spamassassin/.spamassassin drwx-- 3 spamd spamd 4096 Jan 12 05:01 /var/lib/spamassassin/.spamassassin/ Now, I have two questions: 1. Do I have to create the file user_prefs manually? 2. What are the correct permissions for the directory and the file? Thanks in advance. John
