Hello,
At 09:42 14-07-2014, The IESG wrote:
A new IETF working group has been proposed in the Applications Area. The
[snip]
Charter:
Domain-based Message Authentication, Reporting & Conformance (DMARC)
uses existing mail authentication technologies (SPF and DKIM) to
extend validation to the RFC5322.From field. DMARC uses DNS records
to add policy-related requests for receivers and defines a feedback
mechanism from receivers back to domain owners. This allows a domain
owner to advertise that mail can safely receive differential
handling, such as rejection, when the use of the domain name in the
From field is not authenticated. Existing deployment of DMARC has
demonstrated utility at internet scale, in dealing with significant
email abuse, and has permitted simplifying some mail handling
processes.
There are some mail services who provide mailboxes with mailing lists
impediments.
The existing base specification is being submitted as an Independent
Submission to become an Informational RFC.
In a message dated April 22, I commented as follows:
Section 16 describes IANA registry updates. I suggest contacting the
IETF Application Directors for information about the procedure to be
followed for the registry updates.
My reading of the sentence about "Informational RFC" (quoted above)
is that the IESG concluded that the base specification can be
published without any changes (see Point 4 or 5 in BCP 92).
However, DMARC is problematic for mail that does not flow from
operators having a relationship with the domain owner, directly to
receivers operating the destination mailbox. Examples of such
"indirect" flows are mailing lists, publish-to-friend functionality,
mailbox forwarding (".forward"), and third-party services that send
on behalf of clients. The working group will explore possible updates
and extensions to the specifications in order to address limitations
and/or add capabilities. It will also provide technical
implementation guidance and review possible enhancements elsewhere in
the mail handling sequence that could improve could DMARC
compatibility.
The above is well-written.
Specifications produced by the working group will ensure preservation
of DMARC utility for detecting unauthorized use of domain names,
while improving the identification of legitimate sources that do not
currently conform to DMARC requirements. Issues based on operational
experience and/or data aggregated from multiple sources will be given
priority.
The working group will seek to preserve interoperability with the
installed base of DMARC systems, and provide detailed justification
for any non-interoperability. As the working group develops solutions
to deal with indirect mail flows, it will seek to maintain the
end-to-end nature of existing identifier fields in mail, in
particular avoiding solutions that require rewriting of originator
fields.
The last paragraph above sets a high bar for changes. As a note,
some mailing lists have already implemented a "via" rewrite.
Working group activities will pursue three tracks:
1. Addressing the issues with indirect mail flows
The working group will specify mechanisms for reducing or eliminating
the DMARC's effects on indirect mail flows, including deployed
behaviors of many different intermediaries, such as mailing list
managers, automated mailbox forwarding services, and MTAs that
perform enhanced message handling that results in message
modification. Among the choices for addressing these issues are:
- A form of DKIM signature that is better able to survive transit
through intermediaries.
- Collaborative or passive transitive mechanisms that enable an
intermediary to participate in the trust sequence, propagating
authentication directly or reporting its results.
What is the meaning of "collaborative or passive transitive mechanisms"?
- Message modification by an intermediary, to avoid authentication
failures, such as by using specified conventions for changing
the aligned identity.
Consideration also will be given to survivable authentication through
sequences of multiple intermediaries.
2. Reviewing and improving the base DMARC specification
This is going to be a lot of (IETF) work and there will likely be
vigorous discussions.
The working group will not develop additional mail authentication
technologies, but may document authentication requirements that are
desirable.
The base specification relies on the ability of an email receiver to
determine the organizational domain responsible for sending mail. An
organizational domain is the 'base' name that is allocated from a
public registry; examples of registries include ".com" or ".co.uk".
While the common practice is to use a "public suffix" list to
determine organizational domain, it is widely recognized that this
solution will not scale, and that the current list often is
inaccurate. The task of defining a standard mechanism for identifying
organizational domain is out of scope for this working group. However
the working group can consider extending the base DMARC specification
to accommodate such a standard, should it be developed during the
life of this working group.
I'll defer to the DNS experts on the matter of the "public suffix".
Improvements in DMARC features (identifier alignment, reporting,
policy preferences) will be considered, such as:
- Enumeration of data elements required in "Failure" reports
(specifically to address privacy issues)
- Handling potential reporting abuse
- Aggregate reporting to support additional reporting scenarios
- Alternate reporting channels
- Utility of arbitrary identifier alignment
- Utility of a formalized policy exception mechanism
3. DMARC Usage
The working group will document operational practices in terms of
configuration, installation, monitoring, diagnosis and reporting. It
will catalog currently prevailing guidelines as well as developing
advice on practices that are not yet well-established but which are
believed to be appropriate.
The group will consider separating configuration and other deployment
information that needs to be in the base spec, from information that
should be in a separate guide.
Among the topics anticipated to be included in the document are:
- Identifier alignment configuration options
- Implementation decisions regarding "pct"
- Determining effective RUA sending frequency
- Leveraging policy caching
- Various options for integrating within an existing flow
- Defining a useful, common set of options for the addresses to
which feedback reports are to be sent
- When and how to use local policy override options
Work Items
----------
Phase I:
Draft description of interoperability issues for indirect mail
flows and plausible methods for reducing them.
Phase II:
Specification of DMARC improvements to support indirect mail flows
Draft Guide on DMARC Usage
Phase III:
Review and refinement of the DMARC specification
Completion of Guide on DMARC Usage
From what I read "the working group charter MUST establish a
timetable for specific work items". The message does not mention any
timetable. In my opinion it will take many years to deliver all the
work items.
The proposed working group will be working on a guide in Phases II
and III. My quick reaction would be to defer that work to after the
specification has been done.
One question that I thought about is whether the work is doable. In
my opinion, what is being proposed is too much. I am taking into
consideration the administrative overhead which is not visible to the IETF.
Regards,
S. Moonesamy