Re: possible bug in Mail::DKIM when keysize is under 1024 bits
On Jan 12, 2015, at 4:58 PM, Mark Martinec mark.martinec...@ijs.si wrote: On January 12, 2015 8:06:00 AM EST, Mark Martinec It would be wrong to assign score to short keys. Kevin A. McGrail wrote: Actually the rfc specifies that keys 512 to 2048 bits must be verified so I think there is a grey area and there is this long-lived key caveat as well. I think if we can make a rule that fires on 1024 bits it's would be good. Fine with me. The score may not be much but it could be helpful. A message with a valid signature but a short DKIM key cannot be scored more severely than an unsigned message, or a message with an invalid signature - none these are currently assigned any score. Seems the score for key 1024 needs to oppose the DKIM score so the end result is zero. signature.asc Description: Message signed with OpenPGP using GPGMail
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: Honeypot email addresses
On Nov 26, 2014, at 10:50 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 26.11.2014 um 19:45 schrieb Franck Martin: On Nov 26, 2014, at 10:19 AM, Matthias Leisi matth...@leisi.net mailto:matth...@leisi.net wrote: Agreed, it is cheap in resources. However, it will be easier to add to a domain blocking list than to add to an IPv6 blocking list. May be first line of defense is the wrong naming. IPv6 blocking lists will be to remove the extreme badness of the Internet domain blocking list is already done with SpamAssassins URIBL only URLs found in the email, that’s very limited. blocking sender domains blindly is error prone because you penalty a legit domain because some faced forged senders You think that spamhaus, SURBL, URIBL, and any other reputable list service would add in their blocking list a legit domain because some faced forged sender? I think they do know the difference, and even in the case they do collateral damage, they provide public resolution forms, as long as the sender knows how to resolve the block... Have you tried to block based on the domain in the envelope from or From: header? What is your experience? My experience says it is very useful. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Honeypot email addresses
On Nov 26, 2014, at 2:15 AM, Kevin A. McGrail kmcgr...@pccc.commailto:kmcgr...@pccc.com wrote: On 11/26/2014 1:53 AM, Matthias Leisi wrote: On Wed, Nov 26, 2014 at 3:45 AM, Franck Martin fmar...@linkedin.commailto:fmar...@linkedin.com wrote: You may want to read https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf I'm well aware of the issues of cache efficiency and query volumes due to the vast address space. The solution to just cut off at /64 is nice, but there will be many legitimate cases where this is will not be good enough. That's why I am convinced that in the end we will need something like a tree walk algorithm, where an intelligent algorithm starts at (let's say) a /32 boundary and then gets responses to the best fitting response. Yes, such an approach might initially double the amount of queries and has an increased risk of not getting DNS responses, but on the other hand such tree information can be nicely cached with reasonably long TTLs, even for the fast-paced DNSBLs out there. Maybe such a tree-walk algorithm is worth an experiment as a SpamAssassin plugin? I could likely ramble about why I don't think the real-world implications will be that large because patterns will emerge. As such, SA Plugins are very safe for experimental work and can be done without any impact on production systems in my experience. I'd support and love to see some experiments in this realm. I think may be you are missing the other point of this document, if there is no valid SPF or DKIM and the message was received over IPv6, then you reject it (or send it to spam). I think such rule can be easily implemented in SA. Just need to put a score of 10 on it :P As for real case scenario, Google, Microsoft and others are already doing just this. As for /64, yes there are hosting providers that have all their customers in the same /64 and other cases like this where infrastructure is not separated by /64 boundaries. I think IPv6 blocking list will be more last resort, than first line of defense (but that’s just me). Note rbldnsd works at /64 by default, with /128 exceptions.
Re: Honeypot email addresses
On Nov 22, 2014, at 4:15 AM, Aban Dokht ml...@abando.de wrote: On 21.11.2014 18:17, Matthias Leisi wrote: We are about to simplify the reporting we previously had, and want to push this especially to detect spam coming in over IPv6. We also have honeypots with enabled IPv6 MX, but SPAM over IPv6 is very, very seldom. But pushing IPv6 anti spam is a good approach. You may want to read https://www.m3aawg.org/sites/maawg/files/news/M3AAWG_Inbound_IPv6_Policy_Issues-2014-09.pdf
Re: DMARC policy check with AskDNS posible?
On Jun 9, 2014, at 11:27 PM, Christian Laußat us...@spamassassin.shambhu.info wrote: Am 10.06.2014 05:53, schrieb Franck Martin: This is not correct. I think it is strange to claim that yahoo or aol, being a co-creator of DMARC and having outstanding engineers in the profession do not know what they are doing. I think that those (co-)creators of DMARC must be different people then those who set the policy. Not true In most documentations there is a warning about setting p=reject too fast. You should start with a few percent of p=quarantaine and slowly rise it to 100%, then do the same with p=reject, start with 10% and slowly rise it to 100%. So, why did e.g. Yahoo jump from p=none directly to p=reject? I believe they needed to do it quickly, and they knew where they were going so..., see http://blog.cloudmark.com/2014/04/29/aols-dmarc-change-fends-off-com-spammers-attack-but-data-breach-still-not-explained/ or http://yahoo.tumblr.com/post/82426971544/an-update-on-our-dmarc-policy-to-protect-our-users Because of the monitoring mode, when you move to p=reject, with all the aggregate reports, you know exactly how much mail you will loose. As you take control of your email streams it becomes a sweet point where fixing exact domain spoofing is more interesting than losing some emails. Your mileage may vary. Yes, but you don't have to set p=reject to know how much mail you would loose. That's what p=none monitoring mode is for. Yes, this is what I said. And if you see that you will loose many mails from mailing lists, it is not wise to change your policy to p=reject without fixing those problems first. Yes, but there are also other factors in consideration, see the above posts DKIM and SPF do not have a reporting to the sender to tell them how many emails were blocked/rejected. DKIM does not have a policy method, only SPF. So as a sender with SPF -all you have no idea how many emails are blocked, very few are willing to take that risk. With DMARC, you know exactly which emails are getting blocked/rejected. DKIM also had a policy method: ADSP. But it wasn't widely implemented and is now the RFC status is now historic. So maybe DMARC is then new ADSP for DKIM? And yes, you are right, it's a huge improvement to have a reporting method. At least if postmasters do care about the reports before changing to a strict policy. Yes AFAIK even Google doesn't reject p=reject any longer. Instead they move those mails into the Spam folder now. AFAIK, none of the current DMARC players changed in any way how they process DMARC. Google still reject on p=reject but also they knew about popular mailing lists with good reputation, and as the spec allows, you can override DMARC for very specific cases. So again, I think it would be nice to have the DMARC policy results as another criteria for SpamAssassin to decide if a mail is Spam or not. yes but in short, If opendmarc is installed, then spamassassin needs to let it do its job, if there is no opendmarc, then it is fine for spamassassin to do that job. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: DMARC policy check with AskDNS posible?
On Jun 7, 2014, at 9:49 PM, Christian Laußat us...@spamassassin.shambhu.info wrote: Am 07.06.2014 19:55, schrieb Franck Martin: As DMARC provide a feedback mechanism to the sender, then it is up to the sender to deal with these issues, you are just following their policy, you don’t need to or have to to second guess them. You can use some whitelists in openDMARC for some streams you really care about, like mailing lists. There are usually not too many. The default option of openDMARC is to not reject, as to avoid if you forgot opendkim or spf, and start to reject all the incoming mail… Once you are happy with the config, you ought to change that option. The problem is that the sender is not the postmaster, so if e.g. yahoo.com had changed its policy to p=reject, many sender had been blocked without even knowing why. There are many postmaster who think they understood DMARC and set a wrong policy. For human interaction DMARC policy should be p=none. And p=reject should only be used for automatic mailing systems e.g. shopping systems and banks. This is not correct. I think it is strange to claim that yahoo or aol, being a co-creator of DMARC and having outstanding engineers in the profession do not know what they are doing. So it's your decision if you would risk to loose some e-mail, but for me it is a just another indicator for SpamAssassin to rate the mail. Because of the monitoring mode, when you move to p=reject, with all the aggregate reports, you know exactly how much mail you will loose. As you take control of your email streams it becomes a sweet point where fixing exact domain spoofing is more interesting than losing some emails. Your mileage may vary. If you let OpenDMARC block on policy failures, why don't you let OpenDKIM block on DKIM failures and SPF-milter on SPF failures? Blocking on only one criteria leads to many false positives. That's the power of SpamAssasin, to combine many rating points and then decide if it*s spam or not. DKIM and SPF do not have a reporting to the sender to tell them how many emails were blocked/rejected. DKIM does not have a policy method, only SPF. So as a sender with SPF -all you have no idea how many emails are blocked, very few are willing to take that risk. With DMARC, you know exactly which emails are getting blocked/rejected. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: DMARC policy check with AskDNS posible?
On Jun 6, 2014, at 10:30 AM, Christian Laußat us...@spamassassin.shambhu.info wrote: Am 05.06.2014 21:48, schrieb Franck Martin: If the policy=reject and the dmarc is fail, then spamassassin should not see the email because opendmarc would have already rejected it (if not it is due to local policy override, so spamassassin should not change that) In the default configuration OpenDMARC doesn't reject on policy failures, it only adds an Authentication-Results header, which I already use in SpamAssassin. But I don't think it's a good idea to reject mail because of DMARC policy failure, there are too man mailing-list and mail forwardings that are not compatible with DMARC requirements. As DMARC provide a feedback mechanism to the sender, then it is up to the sender to deal with these issues, you are just following their policy, you don’t need to or have to to second guess them. You can use some whitelists in openDMARC for some streams you really care about, like mailing lists. There are usually not too many. The default option of openDMARC is to not reject, as to avoid if you forgot opendkim or spf, and start to reject all the incoming mail… Once you are happy with the config, you ought to change that option. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: DMARC policy check with AskDNS posible?
A couple of comments… If the policy=reject and the dmarc is fail, then spamassassin should not see the email because opendmarc would have already rejected it (if not it is due to local policy override, so spamassassin should not change that) So if you reject on dmarc=fail, this may due to p=quarantine or p=none, which would let the message continue through the pipeline up to spamassassin. In the last case p=none (monitoring) it means the sender does not have all its mail stream under control, so adding some marginal points to the dmarc=fail condition, could be fine, but adding a lot of points, means you are going to block/flag emails from the streams the sender does not have under control (like a third party). The sender may also not want all its mail stream under control... In short if you have installed openDMARC, then you don’t need spamassassin, the work has been done. If you don’t have openDMARC then spamassassin may help you. I think assigning small negative points to dmarc=pass could be better, while remaining neutral for all the rest... As for SENDERDOMAIN this is, in most case. the domain in the From: header… However, there is this concept of alignment against the organizational domain, which requires the heuristic of the public suffix list rules. I would be more interested to know, how you could inject the result of DMARC into the bayesian filtering, and how to meaningfully affect its results. On Jun 3, 2014, at 12:43 AM, Christian Laußat us...@spamassassin.shambhu.info wrote: Hi, I'm trying to improve my rules for DMARC policy checking. For now I only use the Authentication-Results header from the OpenDMARC milter as described here: https://kvm.laussat.info/2014/05/19/using-dmarc-in-spamassassin/ To get ride of this dependency, I looked at Mail::SpamAssassin::Plugin::AskDNS. It seems it would be easy to write a DMARC policy check with these rules, e.g.: askdns __DMARC_POLICY_NONE _dmarc._SENDERDOMAIN_ TXT /v=DMARC1;.*p=none;/ askdns __DMARC_POLICY_QUARANTINE _dmarc._SENDERDOMAIN_ TXT /v=DMARC1;.*p=quarantine;/ askdns __DMARC_POLICY_REJECT _dmarc._SENDERDOMAIN_ TXT /v=DMARC1;.*p=reject;/ meta __DMARC_POLICY_ANY__DMARC_POLICY_NONE || __DMARC_POLICY_QUARANTINE || __DMARC_POLICY_REJECT meta DMARC_PASS __DMARC_POLICY_ANY DKIM_VALID_AU SPF_PASS describe DMARC_PASS Message passed DMARC policy check scoreDMARC_PASS -0.5 meta DMARC_FAIL __DMARC_POLICY_ANY !DMARC_PASS __DOS_HAS_LIST_ID !__DOS_HAS_MAILING_LIST describe DMARC_FAIL Message failed DMARC policy check scoreDMARC_FAIL 1.0 My problem now is how to get the _SENDERDOMAIN_ tag for the AskDNS check? If the message is DKIM signed I could use _DKIMDOMAIN_, but what if it's not signed but has a DMARC policy on the domain? Any ideas how to do this without writing a plugin? -- Christian Laußat https://kvm.laussat.info/ signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Plans for a DMARC plugin ???
On Apr 30, 2014, at 5:05 AM, Christian Laußat us...@spamassassin.shambhu.info wrote: Am 30.04.2014 12:34, schrieb Michael Storz: Am 2014-04-30 11:00, schrieb Axb: On 04/30/2014 10:30 AM, Michael Storz wrote: and in the meantime may want to look at http://sourceforge.net/projects/opendmarc/ OpenDMARC is ok for the original goal of DMARC, protecting transactional email, but not for email from normal ISPs like AOL and Yahoo. SA ist at the moment the better and in my eyes the only feasible solution. OpenDMARC also works well as a classifier in front of SA. The default config doesn't reject mails, it only adds an Authentication-Results header which you can use in SA: header DMARC_PASS Authentication-Results =~ /YourAuthserverID; dmarc=pass / describe DMARC_PASS DMARC validation seems valid tflags DMARC_PASS nice scoreDMARC_PASS -1.1 header DMARC_FAIL Authentication-Results =~ /YourAuthserverID; dmarc=fail / describe DMARC_FAIL DMARC validation failed scoreDMARC_FAIL 3.7 I kind of like this idea, because many domains publishes a monitoring policy. So openDMARC may fail the message but still accept it… Anyhow, there are some missing rules in spamassassin to move to better domain responsibility: -From: header is present and there is only one header -extract all domains in envelope-from, from, rcpt-to, sender and make sure they do exists and have either MX, A or record. -extract all the above domains and domains from helo and dkim d= and ensure they are no in spamhaus DBL, SURBL or URIBL - ... signature.asc Description: Message signed with OpenPGP using GPGMail
Re: false positives by FREEMAIL_FORGED_REPLYTO
Interesting, thanks for pointing it out This syntax has been used in a while by some other software, like JIRA, RT, … so not something new. In general, I would say spamassassin needs a few extra rules to now handle domain reputation/blocking (as it seems this is where we are going), I even found some rules are not IPv6 aware. I’m looking for some free time to write such rules and provide them to the community, I think the focus was helping mailman first. ;) On Apr 24, 2014, at 3:52 AM, Michael Storz michael.st...@lrz.de wrote: Since Yahoo and AOL have moved to a DMARC policy of reject, mail senders are changing the way they are sending their emails. Instead of using the email address of an user in RFC5322.From they use their own address and put the address of the user in the Reply-To field. FREEMAIL_FORGED_REPLYTO fires on these emails and produce false positives. From examples taken from log lines of amavisd: From: GIVENNAME_SURNAME_via_LinkedIn_mem...@linkedin.com (dkim:AUTHOR) From: NAME_via_Dropbox_no-re...@dropbox.com (dkim:AUTHOR) Since more and more such emails will occur, for example all web forms will send their emails in this way, the rule does not make sense anymore. -- Michael signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Catching fake LinkedIn invites
May be to give some background and from there please apply what works best for you. Linkedin do DMARC.org, this means all the emails sent from Linkedin infrastructure will pass SPF (be with the mailfrom or helo strings) and be DKIM signed. Furthermore the domain present in all the strings will be aligned. Beware, MTAs on the way may change some of these characteristics. https://dmarcian.com/dmarc-inspector/linkedin.com http://engineering.linkedin.com/email/dmarc-new-tool-detect-genuine-emails There has been talk to do a DMARC like rule in spamassassin. I certainly would prefer people use the openDMARC milter, but I understand a spamassassin rule could be easier/faster to deploy. http://sourceforge.net/projects/opendmarc/ http://www.trusteddomain.org/opendmarc.html The above is my personal advice. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: SPF failure very low score
On Aug 8, 2013, at 10:49 PM, John Hardin jhar...@impsec.org wrote: On Thu, 8 Aug 2013, Quanah Gibson-Mount wrote: For SA 3.4.0, it says in 50_scores.cf: # SPF # Note that the benefit for a valid SPF record is deliberately minimal; it's # likely that more spammers would quickly move to setting valid SPF records # otherwise. The penalties for an *incorrect* record, however, are large. ;) However, .001 does not seem LARGE to me at all. I would expect at least a 1. Right now there is tons of facebook spam out there that clearly fails SPF, such as the following: X-Spam-Status: No, score=2.407 tagged_above=-10 required=3 tests=[BAYES_50=0.8, DKIM_ADSP_ALL=0.8, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, KHOP_BIG_TO_CC=0.001, RDNS_NONE=0.793, SPF_FAIL=0.001, T_HEADER_FROM_DIFFERENT_DOMAINS=0.01] autolearn=no How is .001 in any way considered a large penalty? SPF is _by itself_ not useful as a spam sign. If you're seeing a lot of facebook spam that fails SPF because it's being forged, then a rule that checks SPF_FAIL *IF* the mail claims to be from Facebook, and adds a point or two, would be more reasonable. Facebook dkim signs all their emails with the domain facebookmail.com, so you may have better luck using the ADSP rules...
Re: Creating new rules
On Aug 1, 2013, at 12:44 PM, Benny Pedersen m...@junc.eu wrote: Franck Martin skrev den 2013-07-31 23:06: Now as we move to IPv6, reputation will shift from an IP based type reputation, to a domain based type reputation. Unfortunately, spam assassin seems to be lacking some rules. still missing dmarc spamassassin plugin, there is a dkim_reput but i dont see much help there, it could be bootstrapped if one have own dkim_repution server and reporting based on opendkim and it failed for me with http://www.dkim-reputation.org/ it might work, but would work better if more used it While interesting, I think this is a dead end... There is some IETF work to do some reputation system... not sure exactly what Nevertheless, it does not matter, if it is the right or wrong direction, my question remains: how do I create such a rule? rule for ? grabbing a domain from some headers and checking it with a DNSBL.
Creating new rules
Hi all, I noticed there is no rules to check if the domain in various emails fields are on blocking lists like DBL at spamhaus. I'm willing to work on some of these rules, but I would appreciate any advice to bootstrap the process. If you can reference documents or say something like, look at this rule and this rule, this is close to what you need to do. Thanks.
Re: Creating new rules
On Jul 31, 2013, at 7:43 PM, Jari Fredriksson ja...@iki.fi wrote: 31.07.2013 20:08, Franck Martin kirjoitti: Hi all, I noticed there is no rules to check if the domain in various emails fields are on blocking lists like DBL at spamhaus. I'm willing to work on some of these rules, but I would appreciate any advice to bootstrap the process. If you can reference documents or say something like, look at this rule and this rule, this is close to what you need to do. SpamAssassin will and does check those RBL:s. They are NET rules, and not active when doing -D Hmm, thanks I looked at http://spamassassin.apache.org/tests_3_3_x.html could not find any rule that do the above. Please help. signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Creating new rules
On Jul 31, 2013, at 7:56 PM, Ralf Hildebrandt ralf.hildebra...@charite.de wrote: * Franck Martin fmar...@linkedin.com: I looked at http://spamassassin.apache.org/tests_3_3_x.html could not find any rule that do the above. Please help. That's a bit odd. I found it being mentioned here: http://www.spamhaus.org/faq/section/Spamhaus%20DBL#287 http://spamassassin.1065346.n5.nabble.com/enabling-SpamHaus-DBL-td55862.html http://svn.apache.org/repos/asf/spamassassin/trunk/rules/25_uribl.cf and by all means it should be enabled by default. Ah yes, I saw these rules, but this is to check the domains of urls in the messages, not to check for instance that the domain used in the From: header is on the DBL.
Re: Creating new rules
On Jul 31, 2013, at 10:08 PM, Kevin Miller kevin_mil...@ci.juneau.ak.us wrote: Problem is, the from adddress is often a Joe job - i.e., a forged address, so the domain mentioned there likely doesn't have anything to do with the actual source of the mail. It seems to me that if the domain isn't the actual source of he spam, it can be detrimental to be filtering on it, particularly if Bayes is learning from it or your MTA auto-reports it to RBLs. Why would they use a forged domain which is on a blacklist? I think they would tend to use a domain which is well known with good reputation. As well known domains are getting protected, then they have to move to use their own domain, which happens to appear on blacklist... Now as we move to IPv6, reputation will shift from an IP based type reputation, to a domain based type reputation. Unfortunately, spam assassin seems to be lacking some rules. Nevertheless, it does not matter, if it is the right or wrong direction, my question remains: how do I create such a rule?
Re: Creating new rules
On Jul 31, 2013, at 11:19 PM, RGB Camera zauschne...@gmail.commailto:zauschne...@gmail.com wrote: On Wed, Jul 31, 2013 at 2:06 PM, Franck Martin fmar...@linkedin.commailto:fmar...@linkedin.com wrote: On Jul 31, 2013, at 10:08 PM, Kevin Miller kevin_mil...@ci.juneau.ak.usmailto:kevin_mil...@ci.juneau.ak.us wrote: Problem is, the from adddress is often a Joe job - i.e., a forged address, so the domain mentioned there likely doesn't have anything to do with the actual source of the mail. It seems to me that if the domain isn't the actual source of he spam, it can be detrimental to be filtering on it, particularly if Bayes is learning from it or your MTA auto-reports it to RBLs. Why would they use a forged domain which is on a blacklist? Indeed, if someone uses a forged domain which is on a blacklist in the header of their mail, we want to block that email too. Some smart B2B spammers know about this loophole in SpamAssassin and don't use their domain name in the message body, using it only in the header where the URI checks aren't done. Let me give some background... I'm part of the people that adopted DMARC (cf www.dmarc.orghttp://www.dmarc.org) this provide protection for the domains that are heavily spoofed. Why I'm not keen in reproducing the DMARC checks in spamassassin, because it is better handled via a milter like opendmarc (because of reporting capabilities which is important), I would not make a fuss if I see something like DMARC in spamassassin. During the development of DMARC, we realized that there are a few holes to plug for it to be more effective, as well as realizing, in general, domain reputation will become more and more important. One of this rule, is to check how the From: header is formed cf http://tools.ietf.org/html/draft-ietf-appsawg-malformed-mail-07 and rate negatively when some headers are malformed The other is to extract all the domains from the following fields: envelope from, from: sender, reply-to and helo/ehlo, and check them against DNSBL There may be other rules, but this is what comes to mind, last one is suggested on spamhaus FAQ but does not seem to have made it in spamassassin. While at the moment DMARC is for domains heavily spoofed, the above rules should benefit everyone
