On Feb 27, 2014, at 3:33 AM, J. Gomez <[email protected]> wrote: > On Tuesday, February 25, 2014 8:34 PM [GMT+1=CET], Tim Draegen wrote: >> You guys are accumulating a bit of history of not really talking >> about DMARC, but instead asserting random things that aren't true, >> and then disappearing when asked to do some homework. > > Is it true that if you reject incoming email which fails DMARC validation and > whose sender's policy is REJECT, then you are in for a world of hurt? Yes, it > is true.
True? I shovel male cow excrement upon your assertion. Applying p=reject on behalf of senders that ask for it barely ever hurts. If ever. I have been using DMARC validation in production for 10 months. When a message results in a DMARC p=reject policy, I reject it. Period. I have the ability to override DMARC policy, and I have the ability to exempt connections from DMARC policy using a whitelist. I have used the whitelist for exactly two IP addresses in 10 months, and in both cases it was for testing commercial mail filtering appliances (trusted forwarders) in front of my mail server. I have the ability to easily apply locally crafted algorithms to determine the probability of ham/spam for any given connection and/or message. I disable SMTP rejections for mail plugins that frequently false positive (DNSBL, SPF, DKIM, GeoIP, FCrDNS, header validity) and instead apply heuristics scoring to plugin results. DMARC remains one of the few plugins that I allow to reject connections on its own. A DMARC policy of p=reject can be followed. Senders that publish such policies [will soon] know that their messages that transit certain list servers that insist upon breaking DKIM signatures will end up rejected. If the sender is willing to live with that, the receiver should be too. Matt > Therefore, DMARC'S p=reject is not something you can trust, nor follow. > Period. There is no clothing that puppet that is going to change this truth > about DMARC > > You can feed a DMARC result of fail plus p=reject as score input into some > system to apply some locally crafted algorithms to determine the probability > of spamminess/phising, but then your are still not following the stated > POLICY of REJECT in the sender's DMARC. That is a truth. About DMARC. > > You can point to links which say "all is relative", "take it with a grain of > salt", etc. That's fine. That, however, does not change the truth that you > cannot trust nor follow DMARC's POLICY of REJECT. You, at most, can take it > into account as a score/weight to do further local processing - OK, but you > are then not REJECTing as per the sender's DMARC policy. Undeniable truth, > that. > > It is the DMARC specification that chose to call it "policy", not > "recommendation". And policy is a policy, not a suggestion. Twisting words > to fit ex-post facto scenarios/realities is not funny. > > Perhaps you can spend your whole working day, day after day, fine tuning your > local DMARC processing secret-sauce. Good for you. Other people do not have > that luxury. > > Regards, > J.Gomez > > _______________________________________________ > dmarc-discuss mailing list > [email protected] > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > > NOTE: Participating in this list means you agree to the DMARC Note Well terms > (http://www.dmarc.org/note_well.html) _______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
