Re: DMARC policy check with AskDNS posible?
After a couple of iterations and re-reading the policy syntax in a DMARC draft, I ended up with the following set of rules ( based on https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7099 ): ifplugin Mail::SpamAssassin::Plugin::AskDNS askdns __DMARC_POLICY_NONE _dmarc._AUTHORDOMAIN_ TXT /^v\s*=DMARC1 (?=\s*;) .* ;\s* p\s*=\s*none \s*(?:;|\z)/x askdns __DMARC_POLICY_QUAR _dmarc._AUTHORDOMAIN_ TXT /^v\s*=DMARC1 (?=\s*;) .* ;\s* p\s*=\s*quarantine \s*(?:;|\z)/x askdns __DMARC_POLICY_REJECT _dmarc._AUTHORDOMAIN_ TXT /^v\s*=DMARC1 (?=\s*;) .* ;\s* p\s*=\s*reject \s*(?:;|\z)/x meta__DMARC_REJECT !(DKIM_VALID_AU || SPF_PASS) __DMARC_POLICY_REJECT meta__DMARC_QUAR !(DKIM_VALID_AU || SPF_PASS) __DMARC_POLICY_QUAR meta__DMARC_NONE !(DKIM_VALID_AU || SPF_PASS) __DMARC_POLICY_NONE metaDMARC_REJECT__DMARC_REJECT !__VIA_ML score DMARC_REJECT2.1 metaDMARC_REJECT_ML __DMARC_REJECT __VIA_ML score DMARC_REJECT_ML 0.8 metaDMARC_QUAR __DMARC_QUAR !__VIA_ML score DMARC_QUAR 1.8 metaDMARC_QUAR_ML __DMARC_QUAR __VIA_ML score DMARC_QUAR_ML 0.7 endif Mark
Re: DMARC policy check with AskDNS posible?
Am 2014-11-04 18:01, schrieb Mark Martinec: Done, added SENDERDOMAIN and AUTHORDOMAIN tags: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7099 Mark Great work! I also like the idea of checking for weak SPF settings with the SENDERDOMAIN tag, as Steadramon suggested. -- Christian Laußat https://blog.laussat.de
Re: DMARC policy check with AskDNS posible?
2014-06-03 09:43, Christian Laußat wrote: 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.: [...] 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? Done, added SENDERDOMAIN and AUTHORDOMAIN tags: https://issues.apache.org/SpamAssassin/show_bug.cgi?id=7099 Mark
Re: DMARC policy check with AskDNS posible?
On Wed, Jun 18, 2014 at 12:38 PM, Kevin A. McGrail kmcgr...@pccc.com wrote: On 6/18/2014 3:01 AM, Franck Martin wrote: 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. Franck, I've been thinking about this and in the end, for me, SpamAssassin is a testing framework, NOT a blocking framework. And the more tests, the more data I have to gauge the proper disposition. So if opendmarc is installed, I am heavily trending towards the concept If someone publishes ADSP, DKIM, DMARC, SPF, etc. I'll use ALL of these policies to gain as much information about the email as possible. Perhaps I'll use some crazy metas that reflect the spirit of ignoring the other polices but you can be sure I won't be using p=reject to reject but instead score the email higher, etc. In the end DMARC allows you as a receiver to understand better where if a given email is spoofed or not. And that's mainly because it says that SPF can break if DKIM passes and the other way around. Keep in mind that DMARC is also about alignment. Envelope and Header From must align. BTW: ADSP has moved to historical and won't be a good feature any more Jose Borges Ferreira
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 6/18/2014 3:01 AM, Franck Martin wrote: 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. Franck, I've been thinking about this and in the end, for me, SpamAssassin is a testing framework, NOT a blocking framework. And the more tests, the more data I have to gauge the proper disposition. So if opendmarc is installed, I am heavily trending towards the concept If someone publishes ADSP, DKIM, DMARC, SPF, etc. I'll use ALL of these policies to gain as much information about the email as possible. Perhaps I'll use some crazy metas that reflect the spirit of ignoring the other polices but you can be sure I won't be using p=reject to reject but instead score the email higher, etc. Regards, KAM
Re: DMARC policy check with AskDNS posible?
RW: I believe he was referring to policy, so DMARC would override the distinction between hard and soft failure in SPF. Correct. And same goes for DKIM. Once a receiver decide to use DMARC it *must* no longer reject a message only based on SPF or DKIM results. You have always to check both mechanisms and calculate a DMARC result after that. Andreas
Re: DMARC policy check with AskDNS posible?
Benny Pedersen: With what dmarc record is this so? hope my last list post clarify...
Re: DMARC policy check with AskDNS posible?
On 6/10/2014 5:33 PM, s...@andreasschulze.de wrote: Kevin A. McGrail: So theoretically to implement DMARC in SA, we should be ignoring both SPF and ADSP. DMARC work ontop of SFP and DKIM. A message get a DMARC pass if SPF *or* DKIM (or both) signal Thumbs up So ignoring SPF will produce wrong DMARC results at all. I did not mention DKIM. I said SPF and ADSP. And quoted from http://www.dmarc.org/faq.html#g_4 The DMARC standard states in Section 7, Policy Enforcement Considerations, that if a DMARC policy is discovered the receiver must disregard policies advertised through other means such as SPF or ADSP. If DMARC support was programmed into SA, I would have to carefully consider this as a RFC-eeze type must. regards, KAM
Re: DMARC policy check with AskDNS posible?
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. 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? 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. 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. 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. AFAIK even Google doesn't reject p=reject any longer. Instead they move those mails into the Spam folder now. 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. -- Christian Laußat https://kvm.laussat.info/
Re: DMARC policy check with AskDNS posible?
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. Only from reports coming from DMARC-checking mail servers that also provide reports. You may well lose other mail delivery to servers that fail to deliver mail because of DMARC but that don't supply reports to the owning domain, I think? Anthony -- www.fonant.com - Quality web sites Tel. 01903 867 810 Fonant Ltd is registered in England and Wales, company No. 7006596 Registered office: Amelia House, Crescent Road, Worthing, West Sussex, BN11 1QR
Re: DMARC policy check with AskDNS posible?
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. 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. It's not only mailing lists. Many website contact forms set the From: address to be the address of the site visitor who filled in the form. If they have AOL or Yahoo! addresses then the resulting email messages from the web server will not be accepted by any compliant DMARC-checking mail service (AOL, Yahoo!, and more. Currently Google accepts the mail but marks it as coming from a suspicious source, contrary to AOL and Yahoo!'s DMARC policies). The fix is to use the Reply-to: header instead, but there are an awful lot of website forms out there that need fixing! AFAIK even Google doesn't reject p=reject any longer. Instead they move those mails into the Spam folder now. I've seen them in the normal Inbox, but with a highlight saying that they're from a suspicious source. Seems to be a sensible work-around to the sudden p=reject problem that's now blighting website forms and mailing lists all around the world! Anthony -- www.fonant.com - Quality web sites Tel. 01903 867 810 Fonant Ltd is registered in England and Wales, company No. 7006596 Registered office: Amelia House, Crescent Road, Worthing, West Sussex, BN11 1QR
Re: DMARC policy check with AskDNS posible?
On 6/10/2014 2:27 AM, Christian Laußat wrote: 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? That's the way I view it especially based on http://www.dmarc.org/faq.html#g_4 What happens if a sender uses DMARC and ADSP? ADSP enables domain owners to publish a policy telling compliant receivers to reject messages that fail to verify with DKIM. While ADSP never achieved widespread adoption, it was put into production by a number of senders and receivers at different times. The DMARC standard states in Section 7, Policy Enforcement Considerations, that if a DMARC policy is discovered the receiver must disregard policies advertised through other means such as SPF or ADSP. Interested readers may also wish to reference Appendix C, Issues With ADSP In Operation, for more information about how experience with ADSP informed work on DMARC. Because a domain owner has to actively take steps to publish DNS records to request DMARC processing, there should be awareness of any ADSP records that may still be present in DNS. So theoretically to implement DMARC in SA, we should be ignoring both SPF and ADSP. Overall, I think the right avenue is a Feature Request for DMARC support in SA. Can you open a bugzilla issue for that? Regards, KAM
Re: DMARC policy check with AskDNS posible?
Kevin A. McGrail: So theoretically to implement DMARC in SA, we should be ignoring both SPF and ADSP. Kevin, DMARC work ontop of SFP and DKIM. A message get a DMARC pass if SPF *or* DKIM (or both) signal Thumbs up So ignoring SPF will produce wrong DMARC results at all. Andreas
Re: DMARC policy check with AskDNS posible?
On Tue, 10 Jun 2014 23:33:37 +0200 s...@andreasschulze.de wrote: Kevin A. McGrail: So theoretically to implement DMARC in SA, we should be ignoring both SPF and ADSP. Kevin, DMARC work ontop of SFP and DKIM. A message get a DMARC pass if SPF *or* DKIM (or both) signal Thumbs up So ignoring SPF will produce wrong DMARC results at all. I believe he was referring to policy, so DMARC would override the distinction between hard and soft failure in SPF.
Re: DMARC policy check with AskDNS posible?
On 10. jun. 2014 23.33.37 CEST, s...@andreasschulze.de wrote: Kevin A. McGrail: So theoretically to implement DMARC in SA, we should be ignoring both SPF and ADSP. Kevin, DMARC work ontop of SFP and DKIM. A message get a DMARC pass if SPF *or* DKIM (or both) signal Thumbs up So ignoring SPF will produce wrong DMARC results at all. With what dmarc record is this so?
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?
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. 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. 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. -- Christian Laußat https://kvm.laussat.info/
Re: DMARC policy check with AskDNS posible?
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. 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... You are right, DMARC policy pass should be given some negative spam points. But for policy failures your are more flexible using META rules. If DMARC policy fails and the mail comes from a mailing list, I wouldn't give it any spam points, but when it comes directly, it's probably forged and should be given some spam points. 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. That's the point, I have a solution when I use OpenDMARC, I can check the Authentication-Results header. But I want a solution to be independent of OpenDMARC milter. 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 know. AskDNS can handle multiple entries in the _SENDERDOMAIN_ tag, e.g. sub.example.com,example.com. The only problem would be to give sub.example.com a higher priority if both match. So my problem still is how to get the _SENDERDOMAIN_ tag set without writing a plugin. If it's imposible, maybe I'll write a plugin, but I want to keep the check as simple as posible. 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. I don't know why you would inject the results into Bayes, DKIM and SPF are not used in Bayes either afaik. The results from using the OpenDMARC Authentication-Results header are: %SPAM %HAM DMARC_FAIL 21.21 0.85 DMARC_PASS 0.00 39.18 -- Christian Laußat https://kvm.laussat.info/
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
DMARC policy check with AskDNS posible?
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/
