Re: [dmarc-ietf] DMARC ATPS Interop Note

[Douglas Otis <[e-mail]>]

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
>>> <[e-mail]> 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