On 5/11/15 10:28 PM, Hector Santos wrote: > On 5/11/2015 2:56 PM, Douglas Otis wrote: >> >> On 5/10/15 10:08 PM, Murray S. Kucherawy wrote: >>> On Sun, May 10, 2015 at 4:37 PM, Douglas Otis >>> <[email protected]> wrote: >>>> ATPS included an onerous task for any third-party service >>>> likely used on a gratis basis. Each third-party was >>>> expected >>>> to learn specific hash algorithms of each From domain. A >>>> difficult process on top of changing their structure of >>>> DKIM >>>> signatures repeated tens of thousands of times for each >>>> different first party domain. In addition, reputations >>>> based >>>> on the third-party relationship could not be leveraged >>>> because of the optional hashing. >>> I continue to find this repeated claim specious at best. >>> >> Unlike TPA-Label that required NO third-party authentication >> method change, ATPS imposed two significant changes onto >> third-parties: >> >> 1) A need for a new DKIM signature unique for _every_ Author >> domain seen by the mediator. > > It should be off the DMARC record now. Dear Hector,
Yes. DMARC uses SMTP outbound registration confirmation to mitigate DKIM failure. Sender header fields indicate the domain responsible for issuing a message when present. DMARC failed to accommodate the Sender header field for those domains handling normal email exchange. Ignoring the Sender header field is appropriate only when just direct or transactional messages are issued by a domain asserting restrictive DMARC policy. In these cases, there would be little chance either DKIM or outbound registration would be negatively affected. DMARC being unable to assert the domain handles normal email exchanges likely to affect both DKIM and SMTP outbound registration makes its resulting policy requests unreliable and incompatible with RFC5322. Restrictive DMARC policy necessitate special handling of third-party services to retain defined roles of From header fields per RFC5322. Rather than assisting other domains mitigate misapplied policy, domains abusing DMARC are causing munged From header fields and misapplied policy having a dangerous outcome of legitimate messages being misplaced into Spam folders. As such, DMARC should signal when specific authorizations can be obtained by using a uniform reference to either a specific or a default domain or that the Sender header field may offer an optional alignment when likely visible to the recipient. >> 2) A need to determine an _unspecified_ hash unique for each >> Author domain seen by the mediator. > Do we really need a hash? I agree. This required new > tools (Hash calculators, wizard, command line tools, DNS > tools, etc) for DNS admin and sysops to be programmed. > Makes it harder to explore. Third-party authorizations should be uniform, small, and hard to explore. Even to the point of publishing a wildcard mitigating the generation of a large number of RRsets as seen with DNS-SD that even expects this type exploring behavior causing a real DDoS concern. >> Both of these unnecessary and difficult impositions do not >> align with those benefiting (the DMARC domain). Many have not realized double signing is wide open to abuse and will need similar DNS publishing techniques to adhere to a broken window theory. http://en.wikipedia.org/wiki/Broken_windows_theory Few things are more reprehensible than using DMARC to abuse legitimate uses of email just to continue ignoring compromised accounts. TPA-Label did not presume DKIM use, but draft-levine-dkim-conditional would allow a simpler TPA-Label listing scheme signaled using DMARC. Ignore all additional constraints in TPA-Label, since a combined strategy should safely handle a wider range of messages. It seems some have had some difficulty understanding the rate of message handling involved by larger ESPs which makes conditional handling fairly difficult to instrument. Here again, TPA-Label helps. Unlike SPF's high overhead of complex chained resource records, draft-levine-dkim-conditional together with TPA-Label would allow simple single resource record listings. Their retraction allows a quick abuse response. Restoration can be just as quick once abusive accounts have been disabled or disinfected. This represents a simple lightweight scheme that should significantly reduce the rate of abuse by keeping the Sending domains fully in the loop and easily instrumented. Regards, Douglas Otis _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
