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