Re: [dmarc-ietf] WG Review: Domain-based Message Authentication, Reporting & Conformance (dmarc)

[Hector Santos <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>> 
>> Mailing list
>> Address: [e-mail]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc