---- Original Message from: Roland Turner
> You are attempting to characterise DMARC use by a receiver as an
> all-or-nothing proposition and/or as something which receivers would
> benefit from following blindly. This is simply not true. It's not
> what DMARC was designed to do. It's not what any sensible receiver
> would try to do.    
> 
> You are viewing this from the same unworkable viewpoint which led to
> the failures of SPF -all, DomainKeys o=- and ADSP dkim=discardable.
> DMARC has succeeded in large part because it has left this unworkable
> viewpoint behind. The sooner you let go of the errors of the past,
> the sooner you'll be able to make good use of DMARC.

We probably inhabit different universes. In mine, SPF -all "just works" and, 
most importantly, it allows the receiver to outsource onto the sender 100% of 
the blame arising from any non-deliveries because of SPF -all failures; also, 
in my universe DMARC has not "succeeded" -- not yet, at least.

For DMARC to be a viable option for receivers, it has to provide them with a 
non-refutable answer/position for the cases when mail is not delivered because 
of DMARC failures. If receivers are expected to build a custom, fine-tuned, 
on-going maintenance-heavy local-only system to deal with DMARC failure cases, 
because receivers cannot just outsource onto senders the blame for DMARC 
failure cases, then most receivers WILL NOT IMPLEMENT DMARC. My guess is many 
receivers will not implement DMARC after having burned to much time and support 
costs dealing with DMARC failure cases.

> OK, this is perhaps the core of your misunderstanding. That a Domain
> Owner expresses a policy which a receiver elects to ignore does not
> mean that it's not a policy, merely that it's not binding upon the
> receiver. One party's policy is the other party's recommendation,
> suggestion or request.

One party's policy published for the consumption of the receivers, is a policy 
expected to be treated as policy by the receivers, otherwise it would be the 
first party's private-policy and not the first party's published-policy. If 
what I publish as policy is to be regarded as a song, then why do I bother 
publishing a policy instead of a song?

> This is not a contradiction, nor is it ex post
> facto twisting; this is the plain English meaning of the word.     

Policy is policy. That someone opts to not follow it, makes it an ignored 
policy, not a non-policy. Therefore, DMARC's policy of p=reject is best to be 
ignored. Or, in other words, there is not such a thing as a workable policy of 
REJECT in DMARC.

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)

Reply via email to