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
