On 5/24/2014 4:10 PM, Matt Simerson wrote:
On May 24, 2014, at 12:50 PM, Hector Santos <[email protected]> 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?
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
[email protected]
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
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
