Re: Plans for a DMARC plugin ???
On Apr 30, 2014, at 5:05 AM, Christian Laußat 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: 60_adsp_override_dkim.cf (was: Plans for a DMARC plugin ???)
If you want to implement a similar effect to the new yahoo and aol DMARC policy by SpamAssassin, use rules similar to the default rules in 60_adsp_override_dkim.cf: adsp_override yahoo.com custom_med adsp_override yahoo.com.ar custom_med adsp_override yahoo.com.au custom_med adsp_override yahoo.com.br custom_med adsp_override yahoo.com.cn custom_med adsp_override yahoo.com.hk custom_med ... -sm writes: I did a quick verification. The above domains do not publish an ADSP record. Indeed. This is precisely the reason it is useful to *override* by a local rule whatever some domain publishes or not publishes. Mark
60_adsp_override_dkim.cf (was: Plans for a DMARC plugin ???)
Hi Mark, At 04:15 30-04-2014, Mark Martinec wrote: If you want to implement a similar effect to the new yahoo and aol DMARC policy by SpamAssassin, use rules similar to the default rules in 60_adsp_override_dkim.cf: adsp_override yahoo.com custom_med adsp_override yahoo.com.ar custom_med adsp_override yahoo.com.au custom_med adsp_override yahoo.com.br custom_med adsp_override yahoo.com.cn custom_med adsp_override yahoo.com.hk custom_med ... I did a quick verification. The above domains do not publish an ADSP record. Regards, -sm
Re: Plans for a DMARC plugin ???
Am 2014-04-30 14:30, schrieb Mark Martinec: I agree that a DMARC SpamAssassin plugin would be valuable. Michael Storz wrote: How about implementing it in Amavisd-new in addition (I couldn't resist to ask here too :-) I think it more naturally fits into SpamAssassin, contributing to the final score on equal terms with other rules. Also, the bayes auto-learning in SpamAssassin works best when called from SpamAssassin with the final score results - calling it from amavisd would be a hack. Although amavis does handle DKIM by itself (and passes validation results to SpamAssassin, thus avoiding duplicate work and possible breakage due to truncated large mail), it does not know anything about SPF, and I have no desire to deal with SPF there. Mark Mark, I think we have to differentiate between a short and a long term solution. At the moment we need a SA solution, because of all the false positives. But in the future when all of the web forms and mailing lists have been forced to change to a DMARC conformant way of sending emails, a lot of domain owners will publish DMARC reject policies (I already got such request from our customers at least for functional accounts like postmaster, webmaster, support etc. after some very convincing phishing mails with such addresses landed in the inboxes of their users). At that point I think it makes more sense to handle DMARC in amavis than SA, because it will be a hard decision between accepting and rejecting (DMARC-wise) and I hope it will be faster too (we use prequeue filter). Checking of the "accepted" emails if they are ham or spam is then the work of SA and could result in a reject because of spaminess. If amavis would support DMARC now, I already would let it handle Paypal, Facebook and some other senders of transactional emails. I am seeing very few false positives for this kind of emails. And thanks for the DKIM support. Without it we would not have switched to preque filtering. DKIM gives us the possibility to whitelist most ESP emails. Therefore a good amount of traffic will not hit SA, which gives us a consistant result for this kind of emails. However, ESP emails will be marked, therefore users have a third category of email (ham, spam, esp) for their filters. -- Michael
Re: DMARC reports (was Re: Plans for a DMARC plugin ???)
On 4/30/2014 9:16 AM, David F. Skoll wrote: On Wed, 30 Apr 2014 08:34:39 -0400 "Kevin A. McGrail" wrote: [...] rua: Reporting URI(s) for aggregate data ruf: Reporting URI(s) for forensic data I understand that but I find it difficult to believe anyone is bothering to read these and that it will be useful to generate reports when bounces are received. I could be wrong. I believe the rua/ruf addresses almost certainly feed the reports to an automated processing system. agari.com's business model, for example, is to alert domain owners in near real-time when their domain is being abused for phishing attacks or scams. I'm sure they don't have a human combing through the DMARC reports. :) http://agari.com/what-we-do/ All the more reason to be concerned about the report and what information is reported...
DMARC reports (was Re: Plans for a DMARC plugin ???)
On Wed, 30 Apr 2014 08:34:39 -0400 "Kevin A. McGrail" wrote: [...] > > rua: Reporting URI(s) for aggregate data > > ruf: Reporting URI(s) for forensic data > I understand that but I find it difficult to believe anyone is > bothering to read these and that it will be useful to generate > reports when bounces are received. I could be wrong. I believe the rua/ruf addresses almost certainly feed the reports to an automated processing system. agari.com's business model, for example, is to alert domain owners in near real-time when their domain is being abused for phishing attacks or scams. I'm sure they don't have a human combing through the DMARC reports. :) http://agari.com/what-we-do/ Regards, David.
Re: Plans for a DMARC plugin ???
On 4/30/2014 8:04 AM, Michael Storz wrote: Am 2014-04-30 13:36, schrieb Kevin A. McGrail: On 4/30/2014 7:15 AM, Michael Storz wrote: Thanks, your answers are very helpful for solving the problems we are facing. On a related note, if you need, I did implement a modification routine for mailman in mimedefang. Code published at http://lists.roaringpenguin.com/pipermail/mimedefang/2014-April/037324.html As for an SA plugin, I think it will be needed but I believe it is just an overlay on top of existing DKIM and SPF information. If you open a bug for the plugin with your list of desired features, that would be good. Otherwise, to me, I think the features are: - Make sure SPF and DKIM are enabled - Check those results - Check the DMARC policy - If policy is reject or quarantine and the SPF/DKIM fails, give a fairly high score to a rule You are missing the alignment requirements of the RFC5322.From domain with the signing domain (DKIM) and the RFC5321.MailFrom domain (SPF). But this is already implemented in Mail::DMARC. I'm sure I'm missing a lot of things. I don't know that I would want to make this dependent on another module though if it can be easily avoided. When you are ready, open a bug in bugzilla. I think it's a good idea. For DMARC, this will not be a problem, because the address where reports should be sent ist specified in the DMARC record in DNS: rua: Reporting URI(s) for aggregate data ruf: Reporting URI(s) for forensic data Examples: dig +short txt _dmarc.paypal.com "v=DMARC1; p=reject; rua=mailto:d...@rua.agari.com; ruf=mailto:d...@bounce.paypal.com,mailto:d...@ruf.agari.com"; dig +short txt _dmarc.yahoo.com "v=DMARC1; p=reject; sp=none; pct=100; rua=mailto:dmarc-yahoo-...@yahoo-inc.com, mailto:dmarc_y_...@yahoo.com;"; I understand that but I find it difficult to believe anyone is bothering to read these and that it will be useful to generate reports when bounces are received. I could be wrong. Regards, KAM
Re: Plans for a DMARC plugin ???
I agree that a DMARC SpamAssassin plugin would be valuable. Michael Storz wrote: How about implementing it in Amavisd-new in addition (I couldn't resist to ask here too :-) I think it more naturally fits into SpamAssassin, contributing to the final score on equal terms with other rules. Also, the bayes auto-learning in SpamAssassin works best when called from SpamAssassin with the final score results - calling it from amavisd would be a hack. Although amavis does handle DKIM by itself (and passes validation results to SpamAssassin, thus avoiding duplicate work and possible breakage due to truncated large mail), it does not know anything about SPF, and I have no desire to deal with SPF there. Mark
Re: Plans for a DMARC plugin ???
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 Regards Christian Laußat
Re: Plans for a DMARC plugin ???
Am 2014-04-30 13:36, schrieb Kevin A. McGrail: On 4/30/2014 7:15 AM, Michael Storz wrote: Thanks, your answers are very helpful for solving the problems we are facing. On a related note, if you need, I did implement a modification routine for mailman in mimedefang. Code published at http://lists.roaringpenguin.com/pipermail/mimedefang/2014-April/037324.html As for an SA plugin, I think it will be needed but I believe it is just an overlay on top of existing DKIM and SPF information. If you open a bug for the plugin with your list of desired features, that would be good. Otherwise, to me, I think the features are: - Make sure SPF and DKIM are enabled - Check those results - Check the DMARC policy - If policy is reject or quarantine and the SPF/DKIM fails, give a fairly high score to a rule You are missing the alignment requirements of the RFC5322.From domain with the signing domain (DKIM) and the RFC5321.MailFrom domain (SPF). But this is already implemented in Mail::DMARC. Beyond that, I doubt I would support a reporting mechanism. Like reporting viruses, the likelihood of causing a problem and not notifying the correct person is far higher. For DMARC, this will not be a problem, because the address where reports should be sent ist specified in the DMARC record in DNS: rua: Reporting URI(s) for aggregate data ruf: Reporting URI(s) for forensic data Examples: dig +short txt _dmarc.paypal.com "v=DMARC1; p=reject; rua=mailto:d...@rua.agari.com; ruf=mailto:d...@bounce.paypal.com,mailto:d...@ruf.agari.com"; dig +short txt _dmarc.yahoo.com "v=DMARC1; p=reject; sp=none; pct=100; rua=mailto:dmarc-yahoo-...@yahoo-inc.com, mailto:dmarc_y_...@yahoo.com;"; Anyone's thoughts? Regards, KAM -- Michael
Re: Plans for a DMARC plugin ???
Am 2014-04-30 13:15, schrieb Mark Martinec: > >>> On 04/30/2014 10:10 AM, Michael Storz wrote: > >>>> Are there any plans for a DMARC plugin for SpamAssassin? Reacting to a > >>>> DMARC policy of reject (AOL/Yahoo) seems only feasible with > >>>> SpamAssassin because so many exceptions are needed for software which > >>>> destryes DKIM signatures: I agree that a DMARC SpamAssassin plugin would be valuable. How about implementing it in Amavisd-new in addition (I couldn't resist to ask here too :-) Currently the closest thing we have in SpamAssassin is ASDP (Author Domain Signing Practices), implemented by the DKIM plugin. Compared to DMARC it only cares for DKIM signatures and ignores SPF, and offers no reporting. If you want to implement a similar effect to the new yahoo and aol DMARC policy by SpamAssassin, use rules similar to the default rules in 60_adsp_override_dkim.cf: adsp_override yahoo.com custom_med adsp_override yahoo.com.ar custom_med adsp_override yahoo.com.au custom_med adsp_override yahoo.com.br custom_med adsp_override yahoo.com.cn custom_med adsp_override yahoo.com.hk custom_med ... Either replace 'custom_med' with 'all' or 'discard', and/or adjust/increase scores for: score DKIM_ADSP_CUSTOM_LOW 0.001 score DKIM_ADSP_CUSTOM_MED 0.001 score DKIM_ADSP_CUSTOM_HIGH 0.001 score DKIM_ADSP_ALL0 1.1 0 0.8 score DKIM_ADSP_DISCARD0 1.8 0 1.8 score DKIM_ADSP_NXDOMAIN 0 0.8 0 0.9 I have looked at this too. For Paypal this would be ok. But for Payal a pure DMARC rule is easy to write: # _R = DMARC relaxed alignment mode, _S = DMARC strict alignment mode header __LRZ_ENVFROM_PAYPAL_R EnvelopeFrom =~ /paypal\.[a-z]+$/i header __LRZ_FROM_PAYPAL_R From:addr =~ /paypal\.[a-z]+$/i metaLRZ_DMARC_PAYPAL_REJECT (__LRZ_FROM_PAYPAL_R && ! (DKIM_VALID_AU || (__LRZ_ENVFROM_PAYPAL_R && SPF_PASS))) For AOL and Yahoo, there are too many false positives, if you just use the rules without exceptions. Therefore my rules for AOL and Yahoo are much more complicated, but they work without too many false positives in my environment. For GMAIL (I know they did not publish a reject policy) I am still getting a lot of false positives because of all the web applications which use the address of the user as from. And in this case you cannot use normal DMARC rules because of the mixture of the Google organizational domains (gmail.com, googlemail.com, google.com and googlegroups.com) and the different signing domains in the same message :-( At the moment DMARC does not allow more than one organizational domain for alignment. > >>> How could a SA plugin help? > >>> Isn't this something that should be handled at MTA level? Not in my view. The SpamAssassin prides itself with collecting spam scores based on various criteria, the DMARC or ASDP policy is just one of such criteria. If one wants to block mail violating sender policy one can bump up corresponding scores. More useful than hard blacklisting is often the balanced resulting spam score. Yup, that's right. At the moment I am using 5.1 as the score of my reject rules. Bayes and DNSWL can lower it to ham, other firing rules will increase the score to rejecting. Btw, SpamAssassin (as well as amavisd) can be coupled with an MTA as a before-queue filter (milter or proxy), so mail can be rejected there too (not just bounced or tagged or quarantined). Tom writes: > I proposed a DMARC plugin for spamassassin on the dmarc mailing list > last year, to make it easier for people to give DMARC a spin. They > didn't really like the idea (I still do), because a simple plugin Jim P. writes: > wouldn't do the report sending, which is an important part of DMARC. Sending reports can leak data (think: HIPAA). Know what you are leaking to others. Michael writes: Right, therefore nearly no one is sending forensic reports, only aggregate reports. I wouldn't do the reporting at our site, even if offered by a DMARC plugin. Remember SpamCop plugin? I think such feedback is not of high value to a sending or to a policy site. So in summary, I'm in favour of a DMARC SpamAssassin plugin, as SA already has access to SPF and DKIM results. The configuration approaches can mimic the existing ASDP in the DKIM plugin, concepts are very similar (apart from reporting). Mark -- Michael
Re: Plans for a DMARC plugin ???
On 04/30/2014 01:36 PM, Kevin A. McGrail wrote: > On 4/30/2014 7:15 AM, Michael Storz wrote: >> >> Thanks, your answers are very helpful for solving the problems we are >> facing. > On a related note, if you need, I did implement a modification routine > for mailman in mimedefang. Code published at > http://lists.roaringpenguin.com/pipermail/mimedefang/2014-April/037324.html > > As for an SA plugin, I think it will be needed but I believe it is just > an overlay on top of existing DKIM and SPF information. > > If you open a bug for the plugin with your list of desired features, > that would be good. > > Otherwise, to me, I think the features are: > > - Make sure SPF and DKIM are enabled > - Check those results > - Check the DMARC policy > - If policy is reject or quarantine and the SPF/DKIM fails, give a > fairly high score to a rule > > Beyond that, I doubt I would support a reporting mechanism. Like > reporting viruses, the likelihood of causing a problem and not notifying > the correct person is far higher. > The reporting mechanism is working fine in DMARC, you don't have to guess based on message headers or SMTP envelope. The report recipient is well defined, so no reason not to send reports. Making it easy to send (aggregated) reports is probably a bit harder. I did not take a look at Matt Simersons code but I might take a stab at it. Tom signature.asc Description: OpenPGP digital signature
Re: Plans for a DMARC plugin ???
On 4/30/2014 7:15 AM, Michael Storz wrote: Thanks, your answers are very helpful for solving the problems we are facing. On a related note, if you need, I did implement a modification routine for mailman in mimedefang. Code published at http://lists.roaringpenguin.com/pipermail/mimedefang/2014-April/037324.html As for an SA plugin, I think it will be needed but I believe it is just an overlay on top of existing DKIM and SPF information. If you open a bug for the plugin with your list of desired features, that would be good. Otherwise, to me, I think the features are: - Make sure SPF and DKIM are enabled - Check those results - Check the DMARC policy - If policy is reject or quarantine and the SPF/DKIM fails, give a fairly high score to a rule Beyond that, I doubt I would support a reporting mechanism. Like reporting viruses, the likelihood of causing a problem and not notifying the correct person is far higher. Anyone's thoughts? Regards, KAM
Re: Plans for a DMARC plugin ???
> >>> On 04/30/2014 10:10 AM, Michael Storz wrote: > >>>> Are there any plans for a DMARC plugin for SpamAssassin? Reacting to a > >>>> DMARC policy of reject (AOL/Yahoo) seems only feasible with > >>>> SpamAssassin because so many exceptions are needed for software which > >>>> destryes DKIM signatures: I agree that a DMARC SpamAssassin plugin would be valuable. Currently the closest thing we have in SpamAssassin is ASDP (Author Domain Signing Practices), implemented by the DKIM plugin. Compared to DMARC it only cares for DKIM signatures and ignores SPF, and offers no reporting. If you want to implement a similar effect to the new yahoo and aol DMARC policy by SpamAssassin, use rules similar to the default rules in 60_adsp_override_dkim.cf: adsp_override yahoo.com custom_med adsp_override yahoo.com.ar custom_med adsp_override yahoo.com.au custom_med adsp_override yahoo.com.br custom_med adsp_override yahoo.com.cn custom_med adsp_override yahoo.com.hk custom_med ... Either replace 'custom_med' with 'all' or 'discard', and/or adjust/increase scores for: score DKIM_ADSP_CUSTOM_LOW 0.001 score DKIM_ADSP_CUSTOM_MED 0.001 score DKIM_ADSP_CUSTOM_HIGH 0.001 score DKIM_ADSP_ALL0 1.1 0 0.8 score DKIM_ADSP_DISCARD0 1.8 0 1.8 score DKIM_ADSP_NXDOMAIN 0 0.8 0 0.9 > >>> How could a SA plugin help? > >>> Isn't this something that should be handled at MTA level? Not in my view. The SpamAssassin prides itself with collecting spam scores based on various criteria, the DMARC or ASDP policy is just one of such criteria. If one wants to block mail violating sender policy one can bump up corresponding scores. More useful than hard blacklisting is often the balanced resulting spam score. Btw, SpamAssassin (as well as amavisd) can be coupled with an MTA as a before-queue filter (milter or proxy), so mail can be rejected there too (not just bounced or tagged or quarantined). Tom writes: > I proposed a DMARC plugin for spamassassin on the dmarc mailing list > last year, to make it easier for people to give DMARC a spin. They > didn't really like the idea (I still do), because a simple plugin Jim P. writes: > wouldn't do the report sending, which is an important part of DMARC. Sending reports can leak data (think: HIPAA). Know what you are leaking to others. Michael writes: Right, therefore nearly no one is sending forensic reports, only aggregate reports. I wouldn't do the reporting at our site, even if offered by a DMARC plugin. Remember SpamCop plugin? I think such feedback is not of high value to a sending or to a policy site. So in summary, I'm in favour of a DMARC SpamAssassin plugin, as SA already has access to SPF and DKIM results. The configuration approaches can mimic the existing ASDP in the DKIM plugin, concepts are very similar (apart from reporting). Mark
Re: Plans for a DMARC plugin ???
Am 2014-04-30 12:58, schrieb Axb: On 04/30/2014 12:50 PM, Michael Storz wrote: Am 2014-04-30 12:23, schrieb Axb: On 04/30/2014 12:10 PM, Django [BOfH] wrote: HI! Am 30.04.2014 11:14, schrieb Axb: Seems to me that amavisd-new would be the better place to handle this You ned a mail filter, witch can see (!) SPF-Auth and DKIM-Auth while DMARC is checking both results. So the only really good and best place ist to use Milters[1]: SMF-SPF-Milter OpenDKIM-Milter DMARC-Milter and amavisd-new-milter. Don't mix milters with several policyd-daemon! Sers Django [1] https://dokuwiki.nausch.org/doku.php/centos:mail_c6:mta_13 or none at all - depending on what kind of traffic you handle all this goo causes more problems than its worth. :) my unrequested 2 cents That's corect, it depends on the kind of environement you are living. If you operate an email sink, then it is ok to just mark emails as spam. For universities this is different. A lot of students are forwarding their emails to freemail providers like AOL, Google, Hotmail and Yahoo. All of them are using DMARC to reject emails. If you are forwarding emails, which are marked as spam and fail the DMARC check, these emails will be rejected und you will produce backscatter. Even worse, the reputation of your mail server will decrease until the server gets blocked. if doing alot of forwarding, SRS is probably your friend We are doing SRS because GMX and Web.de, two big german freemail providers, are heavily using SPF and no DKIM. But GMAIL tells us we should NOT use SRS because then the alignment requirements of DMARC are destroyed! If you like DMARC or not, in such a scenario you are forced to react. discussing the good and band of DMARC iso outside SA' scope and should be moved to mailop list where the horse is getting beaten to death. EOT for me Thanks, your answers are very helpful for solving the problems we are facing. -- Michael
Re: Plans for a DMARC plugin ???
On 04/30/2014 12:50 PM, Michael Storz wrote: Am 2014-04-30 12:23, schrieb Axb: On 04/30/2014 12:10 PM, Django [BOfH] wrote: HI! Am 30.04.2014 11:14, schrieb Axb: Seems to me that amavisd-new would be the better place to handle this You ned a mail filter, witch can see (!) SPF-Auth and DKIM-Auth while DMARC is checking both results. So the only really good and best place ist to use Milters[1]: SMF-SPF-Milter OpenDKIM-Milter DMARC-Milter and amavisd-new-milter. Don't mix milters with several policyd-daemon! Sers Django [1] https://dokuwiki.nausch.org/doku.php/centos:mail_c6:mta_13 or none at all - depending on what kind of traffic you handle all this goo causes more problems than its worth. :) my unrequested 2 cents That's corect, it depends on the kind of environement you are living. If you operate an email sink, then it is ok to just mark emails as spam. For universities this is different. A lot of students are forwarding their emails to freemail providers like AOL, Google, Hotmail and Yahoo. All of them are using DMARC to reject emails. If you are forwarding emails, which are marked as spam and fail the DMARC check, these emails will be rejected und you will produce backscatter. Even worse, the reputation of your mail server will decrease until the server gets blocked. if doing alot of forwarding, SRS is probably your friend If you like DMARC or not, in such a scenario you are forced to react. discussing the good and band of DMARC iso outside SA' scope and should be moved to mailop list where the horse is getting beaten to death. EOT for me
Re: Plans for a DMARC plugin ???
Am 2014-04-30 12:23, schrieb Axb: On 04/30/2014 12:10 PM, Django [BOfH] wrote: HI! Am 30.04.2014 11:14, schrieb Axb: Seems to me that amavisd-new would be the better place to handle this You ned a mail filter, witch can see (!) SPF-Auth and DKIM-Auth while DMARC is checking both results. So the only really good and best place ist to use Milters[1]: SMF-SPF-Milter OpenDKIM-Milter DMARC-Milter and amavisd-new-milter. Don't mix milters with several policyd-daemon! Sers Django [1] https://dokuwiki.nausch.org/doku.php/centos:mail_c6:mta_13 or none at all - depending on what kind of traffic you handle all this goo causes more problems than its worth. :) my unrequested 2 cents That's corect, it depends on the kind of environement you are living. If you operate an email sink, then it is ok to just mark emails as spam. For universities this is different. A lot of students are forwarding their emails to freemail providers like AOL, Google, Hotmail and Yahoo. All of them are using DMARC to reject emails. If you are forwarding emails, which are marked as spam and fail the DMARC check, these emails will be rejected und you will produce backscatter. Even worse, the reputation of your mail server will decrease until the server gets blocked. If you like DMARC or not, in such a scenario you are forced to react. -- Michael
Re: Plans for a DMARC plugin ???
On 04/30/2014 12:35 PM, Michael Storz wrote: Am 2014-04-30 11:08, schrieb Tom Hendrikx: On 04/30/2014 11:00 AM, Axb wrote: On 04/30/2014 10:30 AM, Michael Storz wrote: Am 2014-04-30 10:23, schrieb Axb: On 04/30/2014 10:10 AM, Michael Storz wrote: Are there any plans for a DMARC plugin for SpamAssassin? Reacting to a DMARC policy of reject (AOL/Yahoo) seems only feasible with SpamAssassin because so many exceptions are needed for software which destryes DKIM signatures: - mailing lists - MS Exchange - Novell GroupWise - Lotus Domino Server ??? - web form emails - ESPs ... exceptions, which could be configured via SpamAssassin rules. How could a SA plugin help? Isn't this something that should be handled at MTA level? Well, we are using amavisd-new in prequeue filtering mode. In our configuration a score of 5 will quarantine an email, a score of 10 will reject the email. You can submit a feature request in SA's bugzilla and in the meantime may want to look at http://sourceforge.net/projects/opendmarc/ I proposed a DMARC plugin for spamassassin on the dmarc mailing list last year, to make it easier for people to give DMARC a spin. They didn't really like the idea (I still do), because a simple plugin wouldn't do the report sending, which is an important part of DMARC. Regards, Tom Matt Simerson (who is on DMARC-diskuss) already did the necessary work (Mail::DMARC) which allows to programm a full featured plugin with reporting. Therefore writing a plugin is not that difficult anymore. Writing a plugin isn't that difficult, but somebody has to do it. Code submissions are welcome and may be added to SA setup after review, etc. Any takers?
Re: Plans for a DMARC plugin ???
Am 2014-04-30 12:10, schrieb Django [BOfH]: HI! Am 30.04.2014 11:14, schrieb Axb: Seems to me that amavisd-new would be the better place to handle this You ned a mail filter, witch can see (!) SPF-Auth and DKIM-Auth while DMARC is checking both results. So the only really good and best place ist to use Milters[1]: SA already gives you the information of DKIM and SPF, you just have to feed it to a DMARC plugin. -- Michael
Re: Plans for a DMARC plugin ???
Am 2014-04-30 11:33, schrieb Jim Popovitch: On Apr 30, 2014 5:09 AM, "Tom Hendrikx" wrote: > > On 04/30/2014 11:00 AM, Axb wrote: > > On 04/30/2014 10:30 AM, Michael Storz wrote: > >> Am 2014-04-30 10:23, schrieb Axb: > >>> On 04/30/2014 10:10 AM, Michael Storz wrote: > >>>> Are there any plans for a DMARC plugin for SpamAssassin? Reacting to a > >>>> DMARC policy of reject (AOL/Yahoo) seems only feasible with > >>>> SpamAssassin > >>>> because so many exceptions are needed for software which destryes DKIM > >>>> signatures: > >>>> > >>>> - mailing lists > >>>> - MS Exchange > >>>> - Novell GroupWise > >>>> - Lotus Domino Server ??? > >>>> - web form emails > >>>> - ESPs > >>>> ... > >>>> > >>>> exceptions, which could be configured via SpamAssassin rules. > >>> > >>> > >>> How could a SA plugin help? > >>> Isn't this something that should be handled at MTA level? > >> > >> Well, we are using amavisd-new in prequeue filtering mode. In our > >> configuration a score of 5 will quarantine an email, a score of 10 will > >> reject the email. > > > > You can submit a feature request in SA's bugzilla > > > > and in the meantime may want to look at > > http://sourceforge.net/projects/opendmarc/ [1] > > > > I proposed a DMARC plugin for spamassassin on the dmarc mailing list > last year, to make it easier for people to give DMARC a spin. They > didn't really like the idea (I still do), because a simple plugin > wouldn't do the report sending, which is an important part of DMARC. > > Regards, > Tom > Sending reports can leak data (think: HIPAA). Know what you are leaking to others. -Jim P. Right, therefore nearly no one is sending forensic reports, only aggregate reports. -- Michael
Re: Plans for a DMARC plugin ???
Am 2014-04-30 11:08, schrieb Tom Hendrikx: On 04/30/2014 11:00 AM, Axb wrote: On 04/30/2014 10:30 AM, Michael Storz wrote: Am 2014-04-30 10:23, schrieb Axb: On 04/30/2014 10:10 AM, Michael Storz wrote: Are there any plans for a DMARC plugin for SpamAssassin? Reacting to a DMARC policy of reject (AOL/Yahoo) seems only feasible with SpamAssassin because so many exceptions are needed for software which destryes DKIM signatures: - mailing lists - MS Exchange - Novell GroupWise - Lotus Domino Server ??? - web form emails - ESPs ... exceptions, which could be configured via SpamAssassin rules. How could a SA plugin help? Isn't this something that should be handled at MTA level? Well, we are using amavisd-new in prequeue filtering mode. In our configuration a score of 5 will quarantine an email, a score of 10 will reject the email. You can submit a feature request in SA's bugzilla and in the meantime may want to look at http://sourceforge.net/projects/opendmarc/ I proposed a DMARC plugin for spamassassin on the dmarc mailing list last year, to make it easier for people to give DMARC a spin. They didn't really like the idea (I still do), because a simple plugin wouldn't do the report sending, which is an important part of DMARC. Regards, Tom Matt Simerson (who is on DMARC-diskuss) already did the necessary work (Mail::DMARC) which allows to programm a full featured plugin with reporting. Therefore writing a plugin is not that difficult anymore. -- Michael
Re: Plans for a DMARC plugin ???
Am 2014-04-30 11:00, schrieb Axb: On 04/30/2014 10:30 AM, Michael Storz wrote: Am 2014-04-30 10:23, schrieb Axb: On 04/30/2014 10:10 AM, Michael Storz wrote: Are there any plans for a DMARC plugin for SpamAssassin? Reacting to a DMARC policy of reject (AOL/Yahoo) seems only feasible with SpamAssassin because so many exceptions are needed for software which destryes DKIM signatures: - mailing lists - MS Exchange - Novell GroupWise - Lotus Domino Server ??? - web form emails - ESPs ... exceptions, which could be configured via SpamAssassin rules. How could a SA plugin help? Isn't this something that should be handled at MTA level? Well, we are using amavisd-new in prequeue filtering mode. In our configuration a score of 5 will quarantine an email, a score of 10 will reject the email. You can submit a feature request in SA's bugzilla Yes, I could. But this will take too long, to get a solution. I just wanted to know if there is work in progress. 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. -- Michael
Re: Plans for a DMARC plugin ???
On 04/30/2014 12:10 PM, Django [BOfH] wrote: HI! Am 30.04.2014 11:14, schrieb Axb: Seems to me that amavisd-new would be the better place to handle this You ned a mail filter, witch can see (!) SPF-Auth and DKIM-Auth while DMARC is checking both results. So the only really good and best place ist to use Milters[1]: SMF-SPF-Milter OpenDKIM-Milter DMARC-Milter and amavisd-new-milter. Don't mix milters with several policyd-daemon! Sers Django [1] https://dokuwiki.nausch.org/doku.php/centos:mail_c6:mta_13 or none at all - depending on what kind of traffic you handle all this goo causes more problems than its worth. :) my unrequested 2 cents
Re: Plans for a DMARC plugin ???
HI! Am 30.04.2014 11:14, schrieb Axb: > Seems to me that amavisd-new would be the better place to handle this You ned a mail filter, witch can see (!) SPF-Auth and DKIM-Auth while DMARC is checking both results. So the only really good and best place ist to use Milters[1]: SMF-SPF-Milter OpenDKIM-Milter DMARC-Milter and amavisd-new-milter. Don't mix milters with several policyd-daemon! Sers Django [1] https://dokuwiki.nausch.org/doku.php/centos:mail_c6:mta_13 -- "Bonnie & Clyde der Postmaster-Szene!" approved by Postfix-God http://wetterstation-pliening.info http://dokuwiki.nausch.org http://wiki.piratenpartei.de/Benutzer:Django
Re: Plans for a DMARC plugin ???
On Apr 30, 2014 5:09 AM, "Tom Hendrikx" wrote: > > On 04/30/2014 11:00 AM, Axb wrote: > > On 04/30/2014 10:30 AM, Michael Storz wrote: > >> Am 2014-04-30 10:23, schrieb Axb: > >>> On 04/30/2014 10:10 AM, Michael Storz wrote: > >>>> Are there any plans for a DMARC plugin for SpamAssassin? Reacting to a > >>>> DMARC policy of reject (AOL/Yahoo) seems only feasible with > >>>> SpamAssassin > >>>> because so many exceptions are needed for software which destryes DKIM > >>>> signatures: > >>>> > >>>> - mailing lists > >>>> - MS Exchange > >>>> - Novell GroupWise > >>>> - Lotus Domino Server ??? > >>>> - web form emails > >>>> - ESPs > >>>> ... > >>>> > >>>> exceptions, which could be configured via SpamAssassin rules. > >>> > >>> > >>> How could a SA plugin help? > >>> Isn't this something that should be handled at MTA level? > >> > >> Well, we are using amavisd-new in prequeue filtering mode. In our > >> configuration a score of 5 will quarantine an email, a score of 10 will > >> reject the email. > > > > You can submit a feature request in SA's bugzilla > > > > and in the meantime may want to look at > > http://sourceforge.net/projects/opendmarc/ > > > > I proposed a DMARC plugin for spamassassin on the dmarc mailing list > last year, to make it easier for people to give DMARC a spin. They > didn't really like the idea (I still do), because a simple plugin > wouldn't do the report sending, which is an important part of DMARC. > > Regards, > Tom > Sending reports can leak data (think: HIPAA). Know what you are leaking to others. -Jim P.
Re: Plans for a DMARC plugin ???
On 04/30/2014 11:08 AM, Tom Hendrikx wrote: On 04/30/2014 11:00 AM, Axb wrote: On 04/30/2014 10:30 AM, Michael Storz wrote: Am 2014-04-30 10:23, schrieb Axb: On 04/30/2014 10:10 AM, Michael Storz wrote: Are there any plans for a DMARC plugin for SpamAssassin? Reacting to a DMARC policy of reject (AOL/Yahoo) seems only feasible with SpamAssassin because so many exceptions are needed for software which destryes DKIM signatures: - mailing lists - MS Exchange - Novell GroupWise - Lotus Domino Server ??? - web form emails - ESPs ... exceptions, which could be configured via SpamAssassin rules. How could a SA plugin help? Isn't this something that should be handled at MTA level? Well, we are using amavisd-new in prequeue filtering mode. In our configuration a score of 5 will quarantine an email, a score of 10 will reject the email. You can submit a feature request in SA's bugzilla and in the meantime may want to look at http://sourceforge.net/projects/opendmarc/ I proposed a DMARC plugin for spamassassin on the dmarc mailing list last year, to make it easier for people to give DMARC a spin. They didn't really like the idea (I still do), because a simple plugin wouldn't do the report sending, which is an important part of DMARC. Seems to me that amavisd-new would be the better place to handle this
Re: Plans for a DMARC plugin ???
On 04/30/2014 11:00 AM, Axb wrote: > On 04/30/2014 10:30 AM, Michael Storz wrote: >> Am 2014-04-30 10:23, schrieb Axb: >>> On 04/30/2014 10:10 AM, Michael Storz wrote: >>>> Are there any plans for a DMARC plugin for SpamAssassin? Reacting to a >>>> DMARC policy of reject (AOL/Yahoo) seems only feasible with >>>> SpamAssassin >>>> because so many exceptions are needed for software which destryes DKIM >>>> signatures: >>>> >>>> - mailing lists >>>> - MS Exchange >>>> - Novell GroupWise >>>> - Lotus Domino Server ??? >>>> - web form emails >>>> - ESPs >>>> ... >>>> >>>> exceptions, which could be configured via SpamAssassin rules. >>> >>> >>> How could a SA plugin help? >>> Isn't this something that should be handled at MTA level? >> >> Well, we are using amavisd-new in prequeue filtering mode. In our >> configuration a score of 5 will quarantine an email, a score of 10 will >> reject the email. > > You can submit a feature request in SA's bugzilla > > and in the meantime may want to look at > http://sourceforge.net/projects/opendmarc/ > I proposed a DMARC plugin for spamassassin on the dmarc mailing list last year, to make it easier for people to give DMARC a spin. They didn't really like the idea (I still do), because a simple plugin wouldn't do the report sending, which is an important part of DMARC. Regards, Tom signature.asc Description: OpenPGP digital signature
Re: Plans for a DMARC plugin ???
On 04/30/2014 10:30 AM, Michael Storz wrote: Am 2014-04-30 10:23, schrieb Axb: On 04/30/2014 10:10 AM, Michael Storz wrote: Are there any plans for a DMARC plugin for SpamAssassin? Reacting to a DMARC policy of reject (AOL/Yahoo) seems only feasible with SpamAssassin because so many exceptions are needed for software which destryes DKIM signatures: - mailing lists - MS Exchange - Novell GroupWise - Lotus Domino Server ??? - web form emails - ESPs ... exceptions, which could be configured via SpamAssassin rules. How could a SA plugin help? Isn't this something that should be handled at MTA level? Well, we are using amavisd-new in prequeue filtering mode. In our configuration a score of 5 will quarantine an email, a score of 10 will reject the email. You can submit a feature request in SA's bugzilla and in the meantime may want to look at http://sourceforge.net/projects/opendmarc/
Re: Plans for a DMARC plugin ???
Am 2014-04-30 10:23, schrieb Axb: On 04/30/2014 10:10 AM, Michael Storz wrote: Are there any plans for a DMARC plugin for SpamAssassin? Reacting to a DMARC policy of reject (AOL/Yahoo) seems only feasible with SpamAssassin because so many exceptions are needed for software which destryes DKIM signatures: - mailing lists - MS Exchange - Novell GroupWise - Lotus Domino Server ??? - web form emails - ESPs ... exceptions, which could be configured via SpamAssassin rules. How could a SA plugin help? Isn't this something that should be handled at MTA level? Well, we are using amavisd-new in prequeue filtering mode. In our configuration a score of 5 will quarantine an email, a score of 10 will reject the email. -- Michael
Re: Plans for a DMARC plugin ???
On 04/30/2014 10:10 AM, Michael Storz wrote: Are there any plans for a DMARC plugin for SpamAssassin? Reacting to a DMARC policy of reject (AOL/Yahoo) seems only feasible with SpamAssassin because so many exceptions are needed for software which destryes DKIM signatures: - mailing lists - MS Exchange - Novell GroupWise - Lotus Domino Server ??? - web form emails - ESPs ... exceptions, which could be configured via SpamAssassin rules. How could a SA plugin help? Isn't this something that should be handled at MTA level?
Plans for a DMARC plugin ???
Are there any plans for a DMARC plugin for SpamAssassin? Reacting to a DMARC policy of reject (AOL/Yahoo) seems only feasible with SpamAssassin because so many exceptions are needed for software which destryes DKIM signatures: - mailing lists - MS Exchange - Novell GroupWise - Lotus Domino Server ??? - web form emails - ESPs ... exceptions, which could be configured via SpamAssassin rules. -- Michael
