Re: [dmarc-ietf] WG Review: Domain-based Message Authentication, Reporti

I would like to see a better integrated, cross-area engineering effort.  There 
is much to do in the integrated area of new domain authorization 
"permission-based" policy concepts.   We have a tendency of repeating the 
similar concepts across proposed multiple protocols.  In an evolved, modern 
SMTP receiver, it could perform 3-6 or more DNS redundant lookups for each 
transaction, and they are not flexible enough to be lumped together.

--
Hector Santos
http://www.santronics.com

> On Jul 20, 2014, at 2:23 PM, Eric Burger 
> <eburger(_at_)standardstrack(_dot_)com> wrote:
>
> I will not comment on the 85 messages in the thread.  However, I would like 
> to point out that STIR is working on a similar problem with similar goals but 
> in a more constrained environment.  I would offer coordination between WG’s, 
> should DMARC be chartered, would be “a good thing.”
>
> > On Jul 14, 2014, at 12:42 PM, The IESG <iesg-secretary(_at_)ietf(_dot_)org> 
> > wrote:
> >
> > A new IETF working group has been proposed in the Applications Area. The
> > IESG has not made any determination yet. The following draft charter was
> > submitted, and is provided for informational purposes only. Please send
> > your comments to the IESG mailing list (iesg at ietf.org) by 2014-07-24.
> >
> > Domain-based Message Authentication, Reporting & Conformance (dmarc)
> > ------------------------------------------------
> > Current Status: Proposed WG
> >
> > Assigned Area Director:
> > Pete Resnick <presnick(_at_)qti(_dot_)qualcomm(_dot_)com>
> >
> > Mailing list
> > Address: dmarc(_at_)ietf(_dot_)org
> > To Subscribe: https://www.ietf.org/mailman/listinfo/dmarc
> > Archive: http://www.ietf.org/mail-archive/web/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 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.
> >
> >  The existing base specification is being submitted as an Independent
> >  Submission to become an Informational RFC.
> >
> >  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.
> >
> >  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.
> >
> >
> >  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.
> >
> >     - 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
> >  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.
> >
> >  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
> >
> >
> >
> >  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
> >
> >
> > Milestones:
> >
> > TBD
> _______________________________________________
> dmarc mailing list
> dmarc(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/dmarc