On 8/18/2014 8:31 AM, Tim Draegen wrote:
> If you have comments on the milestones, please provide them by August 25th.
> Have fun,
Mostly small, suggested wording tweaks, to improve clarity and possibly
avoid some unnecessary points of controversy.
There's one (???) with a change I think is correct. If it isn't the
reason needs to be made explicit.
> [1] http://datatracker.ietf.org/wg/dmarc/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 extend -> and extends
DKIM and SPF don't do the extending. DMARC does. DKIM and SPF are
merely underpinnings.
> 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
internet -> Internet
> email abuse, and has permitted simplifying some mail handling
> processes. However, DMARC is problematic for mail that does not flow
for mail that does not flow -> for indirect mail flows that are not
> from operators having a relationship with the domain owner, directly
directly -> and directl
('direct' vs. 'indirect' is an essential issue and the terminology needs
to be established here, to make the late use clear.)
> to receivers operating the destination mailbox (for example, mailing
mailbox ( for mailing -> mailbox. Examples include mailing
> lists, publish-to-friend functionality, mailbox forwarding via
> ".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
specifications -> specifications
> capabilities. It will also provide technical implementation guidance
> and review possible enhancements elsewhere in the mail handling
> sequence that could improve DMARC compatibility.
>
> The existing DMARC base specification has been submitted as an
> Independent Submission to become an Informational RFC.
>
> Specifications produced by the working group will ensure preservation
> of DMARC utility for detecting unauthorized use of domain names,
hmmm. on reflection, this works better as a positve:
utility for detecting authorized use of domain names
Use for detecting unauthorized use is far more complicated and
potentially controversial. Use for detecting authorized use is
straightforward.
> 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.
>
> 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
delete [the]
> 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
handling that -> handling, which
(if only to reduce the number of 'that's in the sentence...)
> 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.
>
> - 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
>
> The working group will not develop additional mail authentication
> technologies, but may document authentication requirements that are
document authentication -> document additional authentication
(???)
> desirable.
If they are 'desireable' they are not 'requirements'. If they are
requirements they are not merely de
