On 7/1/14 11:00 AM, Dave Crocker wrote:
I've looked over the small amount of mail posted about the draft charter
and do not see any changes mandated.
Nothing mandated, but here are some changes that I think clarify and/or
simplify. You can find a diff here:
<https://www.ietf.org/rfcdiff?url1=http%3A%2F%2Fresnick1.qualcomm.com%2Fdmarc-charter-00.txt&difftype=--html&submit=Go%21&url2=http%3A%2F%2Fresnick1.qualcomm.com%2Fdmarc-charter-00a.txt>
Details below (including a question). Let me know if you've got any
concerns.
I think we can get this to the IESG for review before Toronto.
Domain-based Message Authentication, Reporting& Conformance (DMARC)
extends stable, domain-level validation to the RFC5322.From field. DMARC
builds upon existing mail authentication technologies (SPF and DKIM),
using DNS records to add policy-related requests for receivers and
defining a feedback mechanism from receivers back to domain owners. This
can allow a domain owner to advertise that mail, which does not
authenticate use of the domain name in the From field, can safely
receive differential handling, such as rejection. Existing deployment of
DMARC has demonstrated utility at internet scale, in dealing with
significant email abuse, and has permitted simplifying some mail
handling processes.
Simplifying:
"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."
Then move this bit up:
The existing base specification is being submitted as an Independent
Submission to become an Informational RFC.
and put a paragraph break.
The working group will seek to preserve interoperability with the
installed base of DMARC systems, and will provide careful justification
for any non-interoperability.
I think we can strike the word "careful". It doesn't add anything.
The working group will seek to maintain
the viability of stable domain-level identifiers in mail, and will
document existing mail streams that do not conform to the DMARC model.
I'm not sure what this means. Can someone explain?
Working group activities will pursue three tracks:
1. Inter-Specification -- Organize and document "DMARC
interoperability issues", developing suggestions for
improvements
" 1. Addressing the issues with indirect mail flows"
It wasn't clear precisely what was being talked about.
The working group will document the effects of DMARC 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.
The working group will consider mechanisms for reducing or eliminating
the DMARC's effects on indirect mail flows. Among the choices are:
We can make this smaller:
"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:"
The specific work items appear below, so I think we can keep it simple here.
2. Intra-Specification -- Audit each part of the DMARC
specification (reporting, policy, auth), making improvements as
appropriate.
" 2. Reviewing and improving the base DMARC specification"
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 basic domain name obtained through a public
registry, such as example.com or example.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 think we can strike the second sentence. Other than reducing this
being marked as spam ;-), I don't think it adds anything. I have no
better understanding of what an organizational domain is from those two
examples. (So is my organizational domain "qti.qualcomm.com" or
"qualcomm.com"? Is it more like example.com or example.co.uk, or is it
something different?) I think the most we're going to be able to say is
that an organizational domain is the domain that represents the top
level of the organization, which doesn't help much.
3. DMARC Usage
The working group will deliver an implementation and deployment guide.
The guide will catalog best current operational practices in terms of
configuration, installation, monitoring, diagnosis and reporting. It
will also develop advice on practices that are not yet well-established
but which are believed to be appropriate.
Simplifying again:
" 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."
Goals and milestones
--------------------
Phase I:
Draft description of interoperability issues and plausible methods
for eliminating or reducing them. This will not include final choices.
Draft Guide on DMARC Usage
Phase II:
Specification of DMARC improvements to support better
interoperability
Review and refinement of the DMARC specification
Phase III:
Completion of Guide on DMARC Usage
First, I think the title should be "Work items". We already have a
separate milestones list for documents. Also, I think we should make
Phase I just figuring out the indirect mail flow thing and get some
proposals sorted for that and then bump stuff forward:
"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 address indirect mail flows
Draft Guide on DMARC Usage
Phase III:
Review and refinement of the DMARC specification
Completion of Guide on DMARC Usage"
References
----------
DMARC - http://dmarc.org
SPF - RFC7208
DKIM - RFC6376
Internet Message Format - RFC5322
OAR / Original Authentication Results - draft-kucherawy-original-authres
Using DMARC - draft-crocker-dmarc-bcp-03
There was some mention of adding existing proposals to this list. Seems
like a good idea to me.
That's all I have. Hope you find it helpful.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
