Re: How to protect DKIM signatures: Moving ADSP to Historic, supporting DMARC instead

[Hector Santos <[e-mail]>]

On 10/3/2013 6:25 PM, Douglas Otis wrote:
>
> On Oct 3, 2013, at 1:37 PM, Barry Leiba <[e-mail]> wrote:
>
>> To both Doug and Hector, and others who want to drift in this direction:
>>
>> As I've said before, the question of moving ADSP to Historic is one
>> we're taking on its own, and is not connected to anything we do or
>> don't do with DMARC.  Bringing DMARC into the discussion is a
>> distraction, and, worse, makes it look like there's a tie-in.  There
>> is not.
>
> Dear Berry,
>
> Even John Levine the author had opine along these same lines.  The response to Hector was agreeing a reason should be given, along with agreeing with his justifications.  The tie-in may be limited, but nevertheless DMARC has become the chosen alternative.  It seems if any reasons are given for moving ADSP to historic it also should conjecture why DMARC and not ADSP, unless your point is nothing has been learned?
>

Doug, the whole problem was the middleware, the mailing list software 
or the 3rd party resigners who were either not supporting DKIM, 
ignorant of policy protocols and/or that did wish to have any 1st 
party domain controls dictating what mail can be resigned or not.

If DMARC is the "chosen alternative" we are still repeating the same 
related issues with this Author Domain Domain Policy Protocol as well. 
   The mailing list software needs to support this otherwise we still 
have the same problems as with ADSP.  In short, a subscriber to a list 
using a DOMAIN that is DMARC restrictive will also have a potential to 
cause automated unsubscribe events to members with DMARC compliant 
receivers supporting the DMARC restrictive policies.   Same thing as 
with ADSP, just change the protocol name.

Keep in mind that DMARC promises to offer better ADSP or as it 
documents "Super ADSP," in fact it outlines what seems to be the short 
comings of ADSP:

    http://tools.ietf.org/html/draft-kucherawy-dmarc-base-01#appendix-A.5

    A.5.  Issues With ADSP In Operation

    DMARC has been characterized as a "super-ADSP" of sorts.

    Contributors to DMARC have compiled a list of issues associated with
    ADSP, gained from operational experience, that have influenced the
    direction of DMARC:

    1.  ADSP has no support for subdomains, i.e., the ADSP record for
        example.com does not explicitly or implicitly apply to
        subdomain.example.com.  If wildcarding is not applied, then
        spammers can trivially bypass ADSP by sending from a subdomain
        with no ADSP record.

    2.  Non-existent subdomains are explicitly out of scope in ADSP.
        There is nothing in ADSP that states receivers should simply
        reject mail from NXDOMAINs regardless of ADSP policy (which of
        course allows spammers to trivially bypass ADSP by sending email
        from non-existent subdomains).

    3.  ADSP has no operational advice on when to look up the ADSP
        record.

    4.  ADSP has no support for using SPF as an auxiliary mechanism to
        DKIM.

    5.  ADSP has no support for a slow roll-out, i.e., no way to
        configure a percentage of email on which the receiver should
        apply the policy.  This is important for large-volume senders.

    6.  ADSP has no explicit support for an intermediate phase where the
        receiver quarantines (e.g., sends to the recipient's "spam"
        folder) rather than rejects the email.

    7.  The binding between the "From" header domain and DKIM is too
        tight for ADSP; they must match exactly.


We must consider that the requestor for the ADSP status change has 
also authored a DMARC "BCP:"

    Using DMARC
    http://tools.ietf.org/html/draft-crocker-dmarc-bcp-01

This draft only mentions ADSP once, and very briefly:

    10.  Interaction Issues

    Some issues come into play when DMARC is used in conjunction with one
    or more other services.

    o  Sender using both DMARC and ADSP


Ok, like what?

Lets try to get the issues straight. We are talking about dropping 
work that is already active in replace of some "super-ADSP" protocol.

Can we get it right please?


-- 
HLS