Subject: [dmarc-ietf] Supporting and Updating the IETF DMARC I-D draft

From: Hector Santos <[email-masked]>
Date: Sat, 24 May 2014 15:50:42 -0400

I've begun looking at adding DMARC support into our existing DKIM, 
ADSP, ATPS, ASL framework.  To explore all this, I converted our 
public ADSP/ATPS/ASL Zone Record Creator web-based wizard to use DMARC 
with the ATPS/ASL extensions at:

      DMARC Policy Zone Record Generator and Test Simulator v3.0
      http://www.winserver.com/public/wcdmarc

Testers are welcome to send comments, suggestions to me.

Off hand, I think the DMARC draft needs to be updated for two basic 
fundamental parts:

1) Separate Policy Handling and Reporting.  If I read the draft right, 
reporting is mandatory.  Reporting should not be mandatory to DMARC 
receivers. Not all receivers will want to add this huge overhead 
component just to support the most important part; the security policy 
portion of the protocol.  Reporting is bound to be ignored and the 
DMARC draft should recognize this reality by not making essential nor 
necessary.

2) To address the critical 3rd party Resigner concerns and policy 
semantics, at a minimum, add a new "tps=" tag that says Third Party 
Signers (tps) are allowed with/out an IETF registered authorization 
mechanism.  See the tps= proposal below for this.

With these two basic considerations, we gain lower barriers to 
adoption, faster migration for all segments of the mail system that 
for the most part has took the IETF opponents of the DKIM author 
domain policy framework by surprise. It didn't surprise any of the 
IETF proponents of this DKIM author domain framework, but we were on 
the losing side of the 3rd party vs 1st party signer policy extremely 
rough consensus debates.

This does not suggest that the YAHOOs will begin to allow 3rd party 
signers, but when the proper protocol options available, which are not 
there now, it opens the doors (and eyes) to the possibility to have a 
smoother transition and integration.  It creates the synergism to 
address all parties in the integrated mail network.

About the "tps=" tag, a quick summary of the idea, this tag describes 
a DMARC policy which allows 3rd party signers w/o authorization 
depending on the value of "tps=":

    missing      --> fallback to 1st party DMARC only
    tps=         --> same as missing
    tps=y        --> any 3rd party allowed
    tps=methods  --> registered method(s) available by the domain.

Examples of registered methods:

    tps=atps  rfc6541 DKIM Authorized Third-Party Signatures
    tps=vbr   rfc5518 Vouch By Reference
    tps=tpa   Otis's TPA draft

with multiples allowed:

    tps=vbr,atps,tpa

This says, the domain has records for each VBR, ATPS, and TPA method. 
The receiver should use the first known negotiated method among the 
list. If no method is known by the receiver, it falls back to missing 
as the fail-safer approach.  However, it can be overwritten by adding 
"y" to the end of the methods.

I personally, would like to add additional "asl=" allowed signer list 
tag since it will be more optimal for the majority of domains in the 
market who are bot now interested in having many 3rd party signers, 
but a short list of domains:

    asl=domain-list      comma delimited list of domains

But it may be asking for too much to get "asl=" into the total picture.

-- 
HLS

---

From: Matt Simerson <[email-masked]>
Date: Sat, 24 May 2014 13:10:30 -0700

On May 24, 2014, at 12:50 PM, Hector Santos <[email-masked]> wrote:

> Off hand, I think the DMARC draft needs to be updated for two basic fundamental parts:
> 
> 1) Separate Policy Handling and Reporting.  If I read the draft right, reporting is mandatory.  Reporting should not be mandatory to DMARC receivers. Not all receivers will want to add this huge overhead component just to support the most important part; the security policy portion of the protocol.  Reporting is bound to be ignored and the DMARC draft should recognize this reality by not making essential nor necessary.

Could you point to the areas within the draft that led you to believe that reporting is mandatory? 

Matt

---

From: Hector Santos <[email-masked]>
Date: Sat, 24 May 2014 21:31:21 -0400

> Could you point to the areas within the draft that led you to believe that reporting is mandatory?

In Section 5.1.

    ... A report is to be sent to each listed URI.
    Mail Receivers MAY impose a limit on the number of URIs that receive
    reports, but MUST support at least two.

In section 5.2.  General Record Format

    ri:  .... DMARC implementations MUST
       be able to provide daily reports and SHOULD be able to provide
       hourly reports when requested.  However, anything other than a
       daily report is understood to be accommodated on a best-effort
       basis.

    rua: .... A  Mail Receiver MUST implement support for a "mailto:"
       URI, i.e. the  ability to send a DMARC report via electronic 
mail.
       If not provided, Mail Receivers MUST NOT generate aggregate 
feedback
       reports.

Same with ruf.

In section 6, Policy Enforcement Considerations

    Mail Receivers are only obligated to report reject or quarantine
    policy actions in aggregate feedback reports that are due to DMARC
    policy.  They are not required to report reject or quarantine actions
    that are the result of local policy.  If local policy information is
    exposed, abusers can gain insight into the effectiveness and delivery
    rates of spam campaigns.

    ....

    Mail Receivers SHOULD also implement reporting instructions of DMARC
    in place of any extensions to SPF or DKIM that might enable such
    reporting.

The draft makes it clear that having a feedback, reporting mechanism 
allows for systems to learn how to best use the protocol.  In section 
7, "DMARC Feedback" it says:

    Providing Domain Owners with visibility into how Mail Receivers
    implement and enforce the DMARC mechanism in the form of feedback is
    critical to establishing and maintaining accurate authentication
    deployments.  When Domain Owners can see what effect their policies
    and practices are having, they are better willing and able to use
    quarantine and reject policies.

Also see section 11 "Feedback Mechanism."  And so on Matt, the 
implementation requirement for reporting is peppered all over the 
document.

Do you not think this is the case?  Is there explicit statement that 
says reporting is optional? Do you know of any existing DMARC receiver 
which does not implement reporting but does handle the policy part?

You have to keep in mind, that while DMARC does bring reporting 
structure, the idea of reporting was considered for other author 
domains protocols but came as an option and with suggestions to impose 
local policy limits.  The anonymous domain DMARC policy SHOULD NOT 
mandate this reporting overhead on receivers.   I would suggest the 
DMARC work came from these early discussions. The 2006 DSAP I-D was 
among the first to begin making it an option:

    http://tools.ietf.org/html/draft-santos-dkim-dsap-00#section-4.5

    4.5.  DSAP Tag: r=<abuse-address>

    This tag is optional.  If not defined, the default is no abuse-
    address is available.

    <abuse-address> is either the user-part or a FQDN email address to
    optional send abuse reports.

    Examples:
       r=abuse
       r=[email-masked]

    If only the user-part is defined, then the full address is
    established by using the originating address domain.

    DKIM verifiers have the option to honor or not honor this reporting
    address.  DKIM signers MUST be aware this reporting address may not
    be utilized by verifiers.

    Verifiers should be aware this reporting address can be a source of
    an report attack vector (Section 7.4).  One possible implementation
    considerations would to limit the report to one report only and to
    track the reception and/or response of the reporting.

I have to admit that I am surprise in how popular this feature appears 
to be and underestimated it.  Enabling DMARC myself, I am starting to 
get interesting reports.  Not sure what it all means with the eventual 
redundancy in reporting that needs to be turned off. All I expected 
all along was for compliant receivers to handle the strict policies. 
Its guess its good to know that our domains are being protected at 
DMARC sites.

-- 
HLS