On 9/12/2013 3:28 PM, Dave Crocker wrote: > > There seems to be a pattern that has developed, of demanding that > failure mean literally no adoption. It doesn't mean that. It means > that it has no community traction. ADSP more than qualifies on the > pragmatics of failure. > > d/ >
The pragmatics of failure also can include implementations but see zero payoff in the field. Pure wasted redundant overhead in DNS calls and crypto processing is all that is highly measurable. In our implementation, DKIM and VBR certainly fits in that category. Yet, we did it for its "marketing" value. ADSP is also implemented and deployed. The payoff measured is still another matter. Even if ADSP domains have DKIM=DISCARDABLE, its been hard to add logic to reject or negatively classify failed DKIM messages. Yet, you don't how sites local policies filters are done. Sites and even users might just apply an ADSP DKIM=DISCARDABLE policy rejection to certain high value domains, like PAYPAL.COM but not others. If Authentication-Results headers are used, what is done locally is a matter of local policy. What is to say the same is not possible with DMARC with its p=reject action attribute? I haven't seen any MUA show a different view yet, but I am sure there are some in the field. Some have an icon or indicator but its not always profound. We have the same issue with 3rd party signing problems with DMARC. ADSP has extensions such as TPA, ATPS and ASL that attempts to address authorized 3rd party signatures. There is interest and deployments of these extensions. DMARC will not attempt to address 3rd party signatures. Whats to stop an DMARC extension to emerge which can piggy back off the _DMARC record? -- HLS _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
