draft-ietf-dmarc-psd-05.txt   draft-ietf-dmarc-psd-06.txt 
Network Working Group S. Kitterman Network Working Group S. Kitterman
Internet-Draft fTLD Registry Services Internet-Draft fTLD Registry Services
Intended status: Experimental July 27, 2019 Intended status: Experimental August 10, 2019
Expires: January 28, 2020 Expires: February 11, 2020
DMARC (Domain-based Message Authentication, Reporting, and Conformance) DMARC (Domain-based Message Authentication, Reporting, and Conformance)
Extension For PSDs (Public Suffix Domains) Extension For PSDs (Public Suffix Domains)
draft-ietf-dmarc-psd-05 draft-ietf-dmarc-psd-06
Abstract Abstract
DMARC (Domain-based Message Authentication, Reporting, and DMARC (Domain-based Message Authentication, Reporting, and
Conformance) is a scalable mechanism by which a mail-originating Conformance) is a scalable mechanism by which a mail-originating
organization can express domain-level policies and preferences for organization can express domain-level policies and preferences for
message validation, disposition, and reporting, that a mail-receiving message validation, disposition, and reporting, that a mail-receiving
organization can use to improve mail handling. DMARC policies can be organization can use to improve mail handling. The design of DMARC
applied to individual domains or to all domains within an presumes that domain names represent either nodes in the tree below
organization. The design of DMARC precludes grouping policies for which registrations occur, or nodes where registrations have
domains based on policy published above the organizational level, occurred; it does not permit a domain name to have both of these
such as TLDs (Top Level Domains). Domains at this higher level of properties simultaneously. Since its deployment in 2015, use of
the DNS tree (but not necessarily at the top of the DNS tree) can be DMARC has shown a clear need for the ability to express policy for
collectively referred to as Public Suffix Domains (PSDs). This these domains as well.
document describes an extension to DMARC to enable DMARC
functionality PSDs. Domains at which registrations can occur are referred to as Public
Suffix Domains (PSDs). This document describes an extension to DMARC
to enable DMARC functionality for PSDs.
This document also seeks to address implementations that consider a
domain on a public Suffix list to be ineligible for DMARC
enforcement.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 28, 2020. This Internet-Draft will expire on February 11, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 5
2.1. Conventions Used in This Document . . . . . . . . . . . . 5 2.1. Conventions Used in This Document . . . . . . . . . . . . 5
2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 5 2.2. Public Suffix Domain (PSD) . . . . . . . . . . . . . . . 5
2.3. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Longest PSD . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 5 2.4. Public Suffix Operator (PSO) . . . . . . . . . . . . . . 5
2.5. PSO Controlled Domain Names . . . . . . . . . . . . . . . 5 2.5. PSO Controlled Domain Names . . . . . . . . . . . . . . . 6
2.6. Non-existent Domains . . . . . . . . . . . . . . . . . . 5 2.6. Non-existent Domains . . . . . . . . . . . . . . . . . . 6
3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 6 3. PSD DMARC Updates to DMARC Requirements . . . . . . . . . . . 6
3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 6 3.1. General Updates . . . . . . . . . . . . . . . . . . . . . 6
3.2. Section 6.1 DMARC Policy Record . . . . . . . . . . . . . 6 3.2. Section 6.3 General Record Format . . . . . . . . . . . . 6
3.3. Section 6.3 General Record Format . . . . . . . . . . . . 6 3.3. Section 6.5. Domain Owner Actions . . . . . . . . . . . 7
3.4. Section 6.5. Domain Owner Actions . . . . . . . . . . . 7 3.4. Section 6.6.1. Extract Author Domain . . . . . . . . . . 7
3.5. Section 6.6.3. Policy Discovery . . . . . . . . . . . . 7 3.5. Section 6.6.3. Policy Discovery . . . . . . . . . . . . 7
3.6. Section 7. DMARC Feedback . . . . . . . . . . . . . . . 7 3.6. Section 7. DMARC Feedback . . . . . . . . . . . . . . . 8
4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 4. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 8 4.1. Feedback leakage . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6.1. Subdomain Policy Tag . . . . . . . . . . . . . . . . . . 9 6.1. Subdomain Policy Tag . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 9 7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. The Experiment . . . . . . . . . . . . . . . . . . . 11 Appendix A. The Experiment . . . . . . . . . . . . . . . . . . . 11
A.1. PSD DMARC Privacy Concern Mitigation . . . . . . . . . . 11 A.1. PSD DMARC Privacy Concern Mitigation . . . . . . . . . . 11
A.2. Non-Existent Subdomain Policy . . . . . . . . . . . . . . 12 A.2. Non-Existent Subdomain Policy . . . . . . . . . . . . . . 12
Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 12 Appendix B. DMARC PSD Registry Examples . . . . . . . . . . . . 12
B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 12 B.1. DMARC PSD DNS Query Service . . . . . . . . . . . . . . . 13
B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 12 B.2. DMARC Public Suffix Domain (PSD) Registry . . . . . . . . 13
Appendix C. Implementation . . . . . . . . . . . . . . . . . . . 13 Appendix C. Implementation . . . . . . . . . . . . . . . . . . . 13
C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 13 C.1. Authheaders Module . . . . . . . . . . . . . . . . . . . 13
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
DMARC [RFC7489] provides a mechanism for publishing organizational DMARC [RFC7489] provides a mechanism for publishing organizational
policy information to email receivers. DMARC allows policy to be policy information to email receivers. DMARC allows policy to be
specified for both individual domains and for organizational domains specified for both individual domains and for organizational domains
and their sub-domains within a single organization. For TLDs and and their sub-domains within a single organization. DMARC leverages
domains that exist between TLDs and organization level domains, public suffix lists to determine which domains are organizational
policy can only be published for the exact domain. No method is domains. It presumes that public suffix list listed domains are not
available for such domains to express policy or receive feedback organizational domains and not subject to DMARC processing; domains
reporting for sub-domains. This missing method allows for the abuse are either organizational domains, sub-domains of organizational
of non-existent organizational-level domains and prevents domains, or listed on a public suffix list. For domains listed in a
identification of domain abuse in email. public suffix list, i.e. TLDs and domains that exist between TLDs and
organization level domains, policy can only be published for the
exact domain. No method is available for these domains to express
policy or receive feedback reporting for sub-domains. This missing
method allows for the abuse of non-existent organizational-level
domains and prevents identification of domain abuse in email.
As an example, imagine a country code TLD (ccTLD) which has public As an example, imagine a country code TLD (ccTLD) which has public
subdomains for government and commercial use (.gov.example and subdomains for government and commercial use (.gov.example and
.com.example). Within the .gov.example public suffix, use of DMARC .com.example). Suppose there exists a registered domain
has been mandated and .gov.example has published its own DMARC "tax.gov.example" that is responsible for taxation in this imagined
record: country. However, by exploiting the typically unauthenticated nature
of email, there are regular malicious campaigns to impersonate this
organization that use similar-looking ("cousin") domains such as
"t4x.gov.example". These domains are not registered. Within the
".gov.example" public suffix, use of DMARC has been mandated, so
"gov.example" publishes the following DMARC record:
"v=DMARC1; p=reject; rua=mailto:dmarc@dmarc.service.gov.example" "v=DMARC1; p=reject; rua=mailto:dmarc@dmarc.service.gov.example"
at at
_dmarc.gov.example. _dmarc.gov.example.
This DMARC record provides policy and a reporting destination for This DMARC record provides policy and a reporting destination for
mail sent from @gov.example. However, due to DMARC's current method mail sent from @gov.example. However, due to DMARC's current method
of discovering and applying policy at the organizational domain of discovering and applying policy at the organizational domain
level, the non-existent organizational domain of @tax.gov.example level, the non-existent organizational domain of @tax.gov.example
does not and cannot fall under a DMARC policy. does not and cannot fall under a DMARC policy.
Defensively registering all variants of "tax" is obviously not a
scalable strategy. The intent of this specification, therefore, is
to enhance the DMARC algorithm by enabling an agent receiving such a
message to be able to determine that a relevant policy is present at
"gov.example", which is precluded by the current DMARC algorithm.
This document provides a simple extension to DMARC [RFC7489] to allow This document provides a simple extension to DMARC [RFC7489] to allow
operators of Public Suffix Domains (PSDs) to express policy at the operators of Public Suffix Domains (PSDs) to express policy at the
level of the PSD that covers all organizational domains that do not level of the PSD that covers all organizational domains that do not
explicitly publish DMARC records, extends the DMARC policy query explicitly publish DMARC records, extends the DMARC policy query
functionality to detect and process such a policy, describes receiver functionality to detect and process such a policy, describes receiver
feedback for such policies, and provides controls to mitigate feedback for such policies, and provides controls to mitigate
potential privacy considerations associated with this extension. potential privacy considerations associated with this extension.
This document also provides a new DMARC [RFC7489] tag to indicate This document also provides a new DMARC [RFC7489] tag to indicate
requested handling policy for non-existent subdommains. This is requested handling policy for non-existent subdommains. This is
skipping to change at page 4, line 21 skipping to change at page 4, line 39
different implementations. different implementations.
There are two types of Public Suffix Operators (PSOs) for which this There are two types of Public Suffix Operators (PSOs) for which this
extension would be useful and appropriate: extension would be useful and appropriate:
o Branded PSDs (e.g., ".google"): These domains are effectively o Branded PSDs (e.g., ".google"): These domains are effectively
Organizational Domains as discussed in DMARC [RFC7489]. They Organizational Domains as discussed in DMARC [RFC7489]. They
control all subdomains of the tree. These are effectively private control all subdomains of the tree. These are effectively private
domains, but listed in the Public Suffix List. They are treated domains, but listed in the Public Suffix List. They are treated
as Public for DMARC purposes. They require the same protections as Public for DMARC purposes. They require the same protections
as DMARC Organizational Domains, but are currently excluded. as DMARC Organizational Domains, but are currently unable to
benefit from DMARC.
o Multi-organization PSDs that require DMARC usage (e.g., ".bank"): o Multi-organization PSDs that require DMARC usage (e.g., ".bank"):
Because existing Organizational Domains using this PSD have their Because existing Organizational Domains using this PSD have their
own DMARC policy, the applicability of this extension is for non- own DMARC policy, the applicability of this extension is for non-
existent domains. The extension allows the brand protection existent domains. The extension allows the brand protection
benefits of DMARC to extend to the entire PSD, including cousin benefits of DMARC to extend to the entire PSD, including cousin
domains of registered organizations. domains of registered organizations.
As an example, take the ".gov.example" described above and add that
for this entity emails about tax returns are sent from
tax.gov.example. It would not be surprising if fraudulent emails
were sent purporting to be from taxes.gov.example (taxes is a cousin
of tax - different enough to evade DMARC protection, but similar
enough to potentially confuse users). As defined in DMARC [RFC7489],
a DMARC record could be published for tax.gov.example, but there is
no general solution to publishing a DMARC policy to defend against
abuse of non-existent cousins such as taxes.gov.example. While an
explicit record could be published for this one domain, the universe
of possible cousins is such that this approach does not scale.
Due to the design of DMARC [RFC7489] and the nature of the Internet Due to the design of DMARC [RFC7489] and the nature of the Internet
email architecture [RFC5598], there are interoperability issues email architecture [RFC5598], there are interoperability issues
associated with DMARC [RFC7489] deployment. These are discussed in associated with DMARC [RFC7489] deployment. These are discussed in
Interoperability Issues between DMARC and Indirect Email Flows Interoperability Issues between DMARC and Indirect Email Flows
[RFC7960]. These issues are not typically applicable to PSDs, since [RFC7960]. These issues are not typically applicable to PSDs, since
they (e.g., the ".gov.example" used above) do not typically send they (e.g., the ".gov.example" used above) do not typically send
mail. mail.
2. Terminology and Definitions 2. Terminology and Definitions
skipping to change at page 5, line 24 skipping to change at page 5, line 28
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Public Suffix Domain (PSD) 2.2. Public Suffix Domain (PSD)
The global Internet Domain Name System (DNS) is documented in The global Internet Domain Name System (DNS) is documented in
numerous Requests for Comment (RFC). It defines a tree of names numerous Requests for Comment (RFC). It defines a tree of names
starting with root, ".", immediately below which are Top Level Domain starting with root, ".", immediately below which are Top Level Domain
names such as ".com" and ".us". They are not available for private names such as ".com" and ".us". They are not available for private
registration. In many cases the public portion of the DNS tree is registration. In many cases the public portion of the DNS tree is
more than one level deep. more than one level deep. The domain name structure consists of a
tree of names, each of which is made of a sequence of words
("labels") separated by period characters. The root of the tree is
simply called ".". The Internet community at large, through
processes and policies external to this work, selects points in this
tree at which to register domain names "owned" by independent
organizations. Real-world examples are ".com", ".org", ".us", and
".gov.uk". Names at which such registrations occur are called Public
Suffix Domains (PSDs), and a registration consists of a label
selected by the registrant to which a desirable PSD is appended. For
example, "ietf.org" is a registered domain name, and ".org" is its
PSD.
2.3. Longest PSD 2.3. Longest PSD
Organizational Domain (DMARC [RFC7489] Section 3.2) with one left- The longest PSD is the PSD matching more labels in the domain name
most label removed. under evaluation than any other public suffix list entry.
2.4. Public Suffix Operator (PSO) 2.4. Public Suffix Operator (PSO)
A Public Suffix Operator manages operations within its PSD. A Public Suffix Operator manages operations within its PSD.
2.5. PSO Controlled Domain Names 2.5. PSO Controlled Domain Names
PSO Controlled Domain Names are names in the DNS that are managed by PSO Controlled Domain Names are names in the DNS that are managed by
a PSO and are not available for use as Organizational Domains (the a PSO and are not available for use as Organizational Domains (the
term Organizational Domains is defined in DMARC [RFC7489] term Organizational Domains is defined in DMARC [RFC7489]
skipping to change at page 6, line 13 skipping to change at page 6, line 27
is a broader definition than that in NXDOMAIN [RFC8020]. is a broader definition than that in NXDOMAIN [RFC8020].
3. PSD DMARC Updates to DMARC Requirements 3. PSD DMARC Updates to DMARC Requirements
This document updates DMARC [RFC7489] as follows: This document updates DMARC [RFC7489] as follows:
3.1. General Updates 3.1. General Updates
References to "Domain Owners" also apply to PSOs. References to "Domain Owners" also apply to PSOs.
3.2. Section 6.1 DMARC Policy Record 3.2. Section 6.3 General Record Format
PSD DMARC records are published as a subdomain of the PSD. For the
PSD ".example", the PSO would post DMARC policy in a TXT record at
"_dmarc.example".
3.3. Section 6.3 General Record Format
A new tag is added after fo: A new tag is added after "fo":
np: Requested Mail Receiver policy for non-existent subdomains np: Requested Mail Receiver policy for non-existent subdomains
(plain-text; OPTIONAL). Indicates the policy to be enacted by the (plain-text; OPTIONAL). Indicates the policy to be enacted by the
Receiver at the request of the Domain Owner. It applies only to Receiver at the request of the Domain Owner. It applies only to
non-existent subdomains of the domain queried and not to either non-existent subdomains of the domain queried and not to either
existing subdomains or the domain itself. Its syntax is identical existing subdomains or the domain itself. Its syntax is identical
to that of the "p" tag defined below. If the 'np' tag is absent, to that of the "p" tag defined below. If the 'np' tag is absent,
the policy specified by the "sp" tag (if the 'sp' tag is present) the policy specified by the "sp" tag (if the 'sp' tag is present)
or the policy specified by the "p" tag, if the 'sp' tag is not or the policy specified by the "p" tag, if the 'sp' tag is not
present, MUST be applied for non-existent subdomains. Note that present, MUST be applied for non-existent subdomains. Note that
skipping to change at page 7, line 5 skipping to change at page 7, line 11
the "sp" tag' is updated to read 'Policy applies to the domain the "sp" tag' is updated to read 'Policy applies to the domain
queried and to subdomains, unless subdomain policy is explicitly queried and to subdomains, unless subdomain policy is explicitly
described using the "sp" or "np" tags.' described using the "sp" or "np" tags.'
sp: The sentence 'If absent, the policy specified by the "p" tag sp: The sentence 'If absent, the policy specified by the "p" tag
MUST be applied for subdomains' is updated to read 'If both the MUST be applied for subdomains' is updated to read 'If both the
'sp' tag is absent and the 'np' tag is either absent or not 'sp' tag is absent and the 'np' tag is either absent or not
applicable, the policy specified by the "p" tag MUST be applied applicable, the policy specified by the "p" tag MUST be applied
for subdomains. for subdomains.
3.4. Section 6.5. Domain Owner Actions 3.3. Section 6.5. Domain Owner Actions
In addition to the DMARC domain owner actions, PSOs that require use In addition to the DMARC domain owner actions, PSOs that require use
of DMARC and participate in PSD DMARC ought to make that information of DMARC and participate in PSD DMARC ought to make that information
available to receivers. The mechanism for doing so is one of the available to receivers. The mechanism for doing so is one of the
experimental elements of this document. See the experiment experimental elements of this document. See the experiment
description (Appendix A). description (Appendix A).
3.4. Section 6.6.1. Extract Author Domain
Experience with DMARC has shown that some implementations short-
circuit messages, bypassing DMARC policy application, when the domain
name extracted by the receiver (from the RFC5322.From) is on the
public suffix list used by the receiver. This negates the capability
being created by this specification. Therefore, the following
paragraph is appended to Section 6.6.1 of DMARC [RFC7489]:
Note that domain names that appear on a public suffix list are not
exempt from DMARC policy application and reporting.
3.5. Section 6.6.3. Policy Discovery 3.5. Section 6.6.3. Policy Discovery
A new step between step 3 and 4 is added: A new step between step 3 and 4 is added:
3A. If the set is now empty and the longest PSD (Section 2.3) of the 3A. If the set is now empty and the longest PSD (Section 2.3) of the
Organizational Domain is one that the receiver has determined is Organizational Domain is one that the receiver has determined is
acceptable for PSD DMARC (discussed in the experiment description acceptable for PSD DMARC (discussed in the experiment description
(Appendix A)), the Mail Receiver MUST query the DNS for a DMARC (Appendix A)), the Mail Receiver MUST query the DNS for a DMARC
TXT record at the DNS domain matching the longest PSD TXT record at the DNS domain matching the longest PSD
(Section 2.3) in place of the RFC5322.From domain in the message (Section 2.3) in place of the RFC5322.From domain in the message
(if different). A possibly empty set of records is returned. (if different). A possibly empty set of records is returned.
As an example, for a message with the Organizational Domain of As an example, for a message with the Organizational Domain of
"example.compute.cloudcompany.com.cctld", the query for PSD DMARC "example.compute.cloudcompany.com.example", the query for PSD DMARC
would use "compute.cloudcompany.com.cctld" as the longest PSD would use "compute.cloudcompany.com.example" as the longest PSD
(Section 2.3). The receiver would check to see if that PSD is listed (Section 2.3). The receiver would check to see if that PSD is listed
in the DMARC PSD Registry, and if so, perform the policy lookup at in the DMARC PSD Registry, and if so, perform the policy lookup at
"_dmarc.compute.cloudcompany.com.cctld". "_dmarc.compute.cloudcompany.com.example".
Note: Because the PSD policy query comes after the Organizational Note: Because the PSD policy query comes after the Organizational
Domain policy query, PSD policy is not used for Organizational Domain policy query, PSD policy is not used for Organizational
domains that have published a DMARC policy. Specifically, this is domains that have published a DMARC policy. Specifically, this is
not a mechanism to provide feedback addresses (RUA/RUF) when an not a mechanism to provide feedback addresses (RUA/RUF) when an
Organizational Domain has declined to do so. Organizational Domain has declined to do so.
3.6. Section 7. DMARC Feedback 3.6. Section 7. DMARC Feedback
Operational note for PSD DMARC: For PSOs, feedback for non-existent Operational note for PSD DMARC: For PSOs, feedback for non-existent
skipping to change at page 11, line 28 skipping to change at page 11, line 41
There are two experimental questions addressed in this document: one There are two experimental questions addressed in this document: one
regarding mitigation of PSD related privacy concerns and the other on regarding mitigation of PSD related privacy concerns and the other on
the utility of specifying separate DMARC policies for non-existent the utility of specifying separate DMARC policies for non-existent
sub-domains. sub-domains.
Aditionally, as of the writing of this document operational and Aditionally, as of the writing of this document operational and
policy constraints prevent this experiment from being deployed policy constraints prevent this experiment from being deployed
globally. If the experiment shows that PSD DMARC solves a real globally. If the experiment shows that PSD DMARC solves a real
problem and can be used at a large scale, the results could prove to problem and can be used at a large scale, the results could prove to
be useful in removing constraints outside of the IETF that would be useful in removing constraints outside of the IETF that would
permit broader deployment". permit broader deployment.
A.1. PSD DMARC Privacy Concern Mitigation A.1. PSD DMARC Privacy Concern Mitigation
To mitigate the privacy concerns associated with Multi-organization To mitigate the privacy concerns associated with Multi-organization
PSDs that do not mandate DMARC usage, see Section 4.1, a mechanism to PSDs that do not mandate DMARC usage, see Section 4.1, a mechanism to
indicate which PSDs do not present this privacy risk is appropriate. indicate which PSDs do not present this privacy risk is appropriate.
There are multiple approaches that are possible. There are multiple approaches that are possible.
The experiment is to evaluate different possible approaches. The The experiment is to evaluate different possible approaches. The
experiment will be complete when there is rough consensus on a experiment will be complete when there is rough consensus on a
 End of changes. 24 change blocks. 
65 lines changed or deleted 94 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/