Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section

[Todd Herr]

On Thu, Jun 3, 2021 at 8:27 PM Dave Crocker  wrote:

> On 5/5/2021 11:48 AM, Todd Herr wrote:
>
>
> We would like to achieve rough consensus on this section of text by
> Friday, May 21.
>
> Apologies.  I've only just been able to review this text.  Attached are
> suggested changes, done as a Word document with revision tracking turned on.
>
> It might appear that the edits effect major substance changes to the
> Introduction, but I believe they do not; the intent was to retain the same
> goals for the Introduction.
>
> Changes were driven by:
>
>- Providing better lead-in for readers with less background on the
>document's topic
>- Eliminating detail that is not need in an introduction
>- Minimizing PSO text, since I belive the covered domains have Domain
>Owners whether they are PSOs or not; hence the fact of being a PSO has
>minimal import in the Introduction
>- General wordsmithing, to tighten things up
>
>
> Taking most of Dave's input into account results in an Introduction
section that will read as follows:

begin current proposed text
---
1. Introduction

   Abusive email often includes unauthorized and deceptive use of a

   domain name in the RFC5322.From header field.  The domain typically

   belongs to an organization expected to be known to - and presumably

   trusted by - the recipient.  The Sender Policy Framework ([RFC7208])

   and DomainKeys Identified Mail ([RFC6376]) protocols provide domain-

   level authentication but are not directly associated with the

   RFC5322.From domain.  DMARC leverages them, so that Domain Owners

   publish a DNS record indicating their RFC5322.From field:


   *  Email authentication policies


   *  Level of concern for mail that fails authentication checks


   *  Desire for reports about email use of the domain name



   DMARC can cover non-existent sub-domains, below the "Organizational

   Domain", as well as domains at the top of the name hierarchy,

   controlled by Public Suffix Operators (PSOs).


   As with SPF and DKIM, DMARC classes results as "pass" or "fail".  A

   pass from either SPF or DKIM is required.  Also the passed domain

   must be "aligned" with the RFC5322.From domain.  Domains are said to

   be "in alignment" if they have the same Organizational Domain, which

   is at the top of the domain hierarchy, while having the same

   administrative authority as the RFC5322.From domain.


   A DMARC pass indicates only that the RFC5322.From domain has been

   authenticated for that message.  Of course, authentication does not

   carry an explicit or implicit value assertion about that message or

   about the Domain Owner.  Indeed, a mail-receiving organization that

   performing DMARC validation can choose to follow the Domain Owner's

   requested disposition for authentication failures, and to inform the

   Domain Owner of the mail handling decision for that message.  It also

   might choose different actions.


   For a mail-receiving organization supporting DMARC, a message that

   passes validation is part of a message stream that is reliably

   associated with the RFC5322.From field Domain Owner.  Therefore,

   reputation assessment of that stream by the mail-receiving

   organization is not encumbered by accounting for unauthorized use of

   that domain in the RFC5322.From field.  A message that fails this

   validation is not necessarily associated with the Domain Owner's

   domain and its reputation.


   DMARC, in the associated [DMARC-Aggregate-Reporting] and

   [DMARC-Failure-Reporting] documents, also specifies a reporting

   framework.  Using it, a mail-receiving domain can generate regular

   reports about messages that claim to be from a domain publishing

   DMARC policies, sending those reports to the addresses specified by

   the Domain Owner.


   Use of DMARC creates some interoperability challenges that require

   due consideration before deployment, particularly with configurations

   that can cause mail to be rejected.  These are discussed in
   Section 9.
-end current proposed text
---

I expect that discussion of this topic will continue for some time.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org

Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section

[Dave Crocker]

On 6/3/2021 7:50 PM, Dave Crocker wrote:

(this time without an attachment...)


Interesting.  My own MUA is not showing a received copy of any of my 
postings of the message through the IETF list.  Hence the re-sends, 
guessing at why not.


Finally looked at the IETF's IMAP archive and there they all are. 
Curious.  Anyhow, another round of apologies.


d/
--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section

[Dave Crocker]

(this time without an attachment...)


On 5/5/2021 11:48 AM, Todd Herr wrote:
We would like to achieve rough consensus on this section of text by 
Friday, May 21.



Apologies.  I've only just been able to review this text. Here's a link 
to suggested changes, done as a Word document with revision tracking 
turned on:


   https://www.dropbox.com/s/qmp2t5n1g99l9wj/DMARCbis-Intro-dcrocker.docx?dl=0

   (I suggest looking at the document without the revision tracks being
   displayed.)

It might appear that the edits effect major substance changes to the 
Introduction, but I believe they do not; the intent was to retain the 
same goals for the Introduction.


Changes were driven by:

 * Providing better lead-in for readers with less background on the
   document's topic
 * Eliminating detail that is not need in an introduction
 * Minimizing PSO text, since I belive the covered domains have Domain
   Owners whether they are PSOs or not; hence the fact of being a PSO
   has minimal import in the Introduction
 * General wordsmithing, to tighten things up

d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org

___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section

[Dave Crocker]

On 5/5/2021 11:48 AM, Todd Herr wrote:



We would like to achieve rough consensus on this section of text by 
Friday, May 21.



Apologies.  I've only just been able to review this text. Here's a link 
to suggested changes, done as a Word document with revision tracking 
turned on:


   https://www.dropbox.com/s/qmp2t5n1g99l9wj/DMARCbis-Intro-dcrocker.docx?dl=0

It might appear that the edits effect major substance changes to the 
Introduction, but I believe they do not; the intent was to retain the 
same goals for the Introduction.


Changes were driven by:

 * Providing better lead-in for readers with less background on the
   document's topic
 * Eliminating detail that is not need in an introduction
 * Minimizing PSO text, since I belive the covered domains have Domain
   Owners whether they are PSOs or not; hence the fact of being a PSO
   has minimal import in the Introduction
 * General wordsmithing, to tighten things up

d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org



DMARCbis-Intro-dcrocker.docx
Description: MS-Word 2007 document
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section

[Dave Crocker]

On 5/5/2021 11:48 AM, Todd Herr wrote:



We would like to achieve rough consensus on this section of text by 
Friday, May 21.


Apologies.  I've only just been able to review this text. Attached are 
suggested changes, done as a Word document with revision tracking turned on.


It might appear that the edits effect major substance changes to the 
Introduction, but I believe they do not; the intent was to retain the 
same goals for the Introduction.


Changes were driven by:

 * Providing better lead-in for readers with less background on the
   document's topic
 * Eliminating detail that is not need in an introduction
 * Minimizing PSO text, since I belive the covered domains have Domain
   Owners whether they are PSOs or not; hence the fact of being a PSO
   has minimal import in the Introduction
 * General wordsmithing, to tighten things up

d/

--
Dave Crocker
dcroc...@gmail.com
408.329.0791

Volunteer, Silicon Valley Chapter
Information & Planning Coordinator
American Red Cross
dave.crock...@redcross.org



DMARCbis-Intro-dcrocker.docx
Description: MS-Word 2007 document
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section

[Dotzero]

Overall I'm comfortable with the introduction verbiage. I do have one
concern:

"For a mail-receiving organization supporting DMARC, a message that

   passes validation is part of a message stream that is reliably

   associated with the Domain Owner and/or any, some, or all of the

   Authenticated Identifiers.  Therefore, reputation assessment of that

   stream by the mail-receiving organization does not need to be

   encumbered by accounting for unauthorized use of any domains."



My concern is with "does not need to be encumbered by accounting for
unauthorized use of any domains". This ignores cases such as DNS hijacking
and domain compromise. Perhaps changing it to "does not need to be
encumbered by accounting for unauthorized use of any domains by 3rd party
senders" or  "does not need to be encumbered by accounting for unauthorized
use of any domains by 3rd party originators"

Michael Hammer

On Thu, May 6, 2021 at 8:22 AM Todd Herr  wrote:

> On Thu, May 6, 2021 at 5:47 AM Alessandro Vesely  wrote:
>
>> Todd,
>>
>> does your message assume that the relevant tickets are all accepted as
>> valid
>> indications to alter the spec?  In particular, tickets #52 and #75 have
>> never
>> been discussed on list. I'd guess they'll have to be discussed in their
>> own
>> threads.
>>
>
> I don't know if each of those individual tickets has to be discussed in
> their own threads or not, and I think it's more a decision for the chairs
> to make than for the editors or the working group, but I could be very
> wrong about that.
>
> What I will say is this:
>
>- The design team went off and effectively created a new version of
>draft-ietf-dmarc-dmarcbis, specifically draft-ietf-dmarc-dmarcbis-01. It is
>proposed text, nothing more, nothing less.
>- The design team's work was influenced by those tickets which
>currently show a status of 'infoneeded'.
>- Due to the nature of the text, both of the following are true:
>   - Most, but perhaps not all, of the 'infoneeded' tickets had
>   impacts on multiple sections of draft-ietf-dmarc-dmarcbis-01
>   - Most of the changes to sections of draft-ietf-dmarc-dmarcbis-00
>   that were made in producing draft-ietf-dmarc-dmarcbis-01 were 
> influenced by
>   multiple tickets
>
> Back on April 23, when I posted here about setting expectations, I thought
> at the time that adjudicating each of the infoneeded tickets might be the
> way to go, but upon further reflection I'm not sure that's the case, since
> it can be argued that those tickets were created against a work product
> that no longer exists. It's also true that because those tickets affect the
> wording in multiple sections of the document, adjudicating the -00 tickets
> can theoretically result in a morass of edits made across multiple sections
> of -01 and subsequent revisions, and everyone eventually losing the plot.
>
> Chairs, your thoughts?
>
>
>> Discussing the resulting text before those tickets entails, for example,
>> noting
>> the cumbersomeness of the locution "severity of concern" where something
>> like
>> "desired disposition" might seem more immediate.  In fact, ticket #85 was
>> only
>> discussed as a side effect of ticket #39, where the consensus, IIRC, was
>> to
>> keep the existing policy names while wavering about how to describe them.
>>
>> The term RFC5322.From is consistently used, notwithstanding ticket #96.
>> For an
>> alternative, let me attempt to define DMARC in terms of its acronym:
>>
>> The Domain-based Message Authentication, Reporting, and Conformance
>> (DMARC)
>> protocol recognizes the prevailing importance of the domain appearing
>> in the
>> From: header field of email messages.  That domain name will be
>> called the
>> Main Identifier in this document.  DMARC leverages the Sender Policy
>> Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376])
>> protocols
>> by focusing the authentication mechanisms they provide toward the Main
>> Identifier.  The Domain Owners corresponding to the Main Identifier
>> are
>> endowed with the possibility to receive feedback reports about
>> authentication results at receivers.  Finally, receivers are provided
>> with
>> the Domain Owners' desiderata about messages that fail
>> authentication, which
>> receivers may or may not decide to conform to.
>>
>>
> As I stated above, I believe the better path for the working group is to
> adjudicate draft-ietf-dmarc-dmarcbis-01. That revision contains a section
> labeled "Introduction", you have proposed alternate text for that section,
> let's discuss that section on the list, come to a consensus, and do it all
> under the auspices of ticket 113.
>
> But that's just my opinion...
>
> --
>
> *Todd Herr* | Sr. Technical Program Manager
> *e:* todd.h...@valimail.com
> *m:* 703.220.4153
>
> This email and all data transmitted with it contains confidential and/or
> proprietary information intended solely for 

Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section

[Todd Herr]

On Thu, May 6, 2021 at 5:47 AM Alessandro Vesely  wrote:

> Todd,
>
> does your message assume that the relevant tickets are all accepted as
> valid
> indications to alter the spec?  In particular, tickets #52 and #75 have
> never
> been discussed on list. I'd guess they'll have to be discussed in their
> own
> threads.
>

I don't know if each of those individual tickets has to be discussed in
their own threads or not, and I think it's more a decision for the chairs
to make than for the editors or the working group, but I could be very
wrong about that.

What I will say is this:

   - The design team went off and effectively created a new version of
   draft-ietf-dmarc-dmarcbis, specifically draft-ietf-dmarc-dmarcbis-01. It is
   proposed text, nothing more, nothing less.
   - The design team's work was influenced by those tickets which
   currently show a status of 'infoneeded'.
   - Due to the nature of the text, both of the following are true:
  - Most, but perhaps not all, of the 'infoneeded' tickets had impacts
  on multiple sections of draft-ietf-dmarc-dmarcbis-01
  - Most of the changes to sections of draft-ietf-dmarc-dmarcbis-00
  that were made in producing draft-ietf-dmarc-dmarcbis-01 were
influenced by
  multiple tickets

Back on April 23, when I posted here about setting expectations, I thought
at the time that adjudicating each of the infoneeded tickets might be the
way to go, but upon further reflection I'm not sure that's the case, since
it can be argued that those tickets were created against a work product
that no longer exists. It's also true that because those tickets affect the
wording in multiple sections of the document, adjudicating the -00 tickets
can theoretically result in a morass of edits made across multiple sections
of -01 and subsequent revisions, and everyone eventually losing the plot.

Chairs, your thoughts?


> Discussing the resulting text before those tickets entails, for example,
> noting
> the cumbersomeness of the locution "severity of concern" where something
> like
> "desired disposition" might seem more immediate.  In fact, ticket #85 was
> only
> discussed as a side effect of ticket #39, where the consensus, IIRC, was
> to
> keep the existing policy names while wavering about how to describe them.
>
> The term RFC5322.From is consistently used, notwithstanding ticket #96.
> For an
> alternative, let me attempt to define DMARC in terms of its acronym:
>
> The Domain-based Message Authentication, Reporting, and Conformance
> (DMARC)
> protocol recognizes the prevailing importance of the domain appearing
> in the
> From: header field of email messages.  That domain name will be called
> the
> Main Identifier in this document.  DMARC leverages the Sender Policy
> Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376])
> protocols
> by focusing the authentication mechanisms they provide toward the Main
> Identifier.  The Domain Owners corresponding to the Main Identifier are
> endowed with the possibility to receive feedback reports about
> authentication results at receivers.  Finally, receivers are provided
> with
> the Domain Owners' desiderata about messages that fail authentication,
> which
> receivers may or may not decide to conform to.
>
>
As I stated above, I believe the better path for the working group is to
adjudicate draft-ietf-dmarc-dmarcbis-01. That revision contains a section
labeled "Introduction", you have proposed alternate text for that section,
let's discuss that section on the list, come to a consensus, and do it all
under the auspices of ticket 113.

But that's just my opinion...

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc

Re: [dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section

[Alessandro Vesely]

Todd,

does your message assume that the relevant tickets are all accepted as valid 
indications to alter the spec?  In particular, tickets #52 and #75 have never 
been discussed on list. I'd guess they'll have to be discussed in their own 
threads.


Discussing the resulting text before those tickets entails, for example, noting 
the cumbersomeness of the locution "severity of concern" where something like 
"desired disposition" might seem more immediate.  In fact, ticket #85 was only 
discussed as a side effect of ticket #39, where the consensus, IIRC, was to 
keep the existing policy names while wavering about how to describe them.


The term RFC5322.From is consistently used, notwithstanding ticket #96.  For an 
alternative, let me attempt to define DMARC in terms of its acronym:


   The Domain-based Message Authentication, Reporting, and Conformance (DMARC)
   protocol recognizes the prevailing importance of the domain appearing in the
   From: header field of email messages.  That domain name will be called the
   Main Identifier in this document.  DMARC leverages the Sender Policy
   Framework ([RFC7208]) and DomainKeys Identified Mail ([RFC6376]) protocols
   by focusing the authentication mechanisms they provide toward the Main
   Identifier.  The Domain Owners corresponding to the Main Identifier are
   endowed with the possibility to receive feedback reports about
   authentication results at receivers.  Finally, receivers are provided with
   the Domain Owners' desiderata about messages that fail authentication, which
   receivers may or may not decide to conform to.

jm2c
Ale
--



On Wed 05/May/2021 20:48:51 +0200 Todd Herr wrote:

Greetings.

This thread will be used to track discussion of the proposed text for the 
Introduction section of draft-ietf-dmarc-dmarcbis-01.


The proposed text was influenced not only by the original text from 
draft-ietf-dmarc-dmarcbis-00, but also by tickets 52, 75, 80, 85, 96 and 108. 
Rather than trying to track changes to the Introduction section through all six 
of those tickets, a new one (Ticket 113 
) has been opened.


The request from the design team/editors for this ticket is as follows:

If you object to some or all of the proposed text, please communicate the
part(s) to which you object, and propose replacement text for those part(s).

We would like to achieve rough consensus on this section of text by Friday, May 
21.

Current proposed text follows, and side-by-side diffs with version -00 can be 
found here 
 



begin current proposed text 
---

1. Introduction

The Sender Policy Framework ([RFC7208]) and DomainKeys Identified

Mail ([RFC6376]) protocols provide domain-level authentication which

is not directly associated with the RFC5322.From domain, and DMARC

builds on those protocols.Using DMARC, Domain Owners that originate

email can publish a DNS TXT record with their email authentication

policies, state their level of concern for mail that fails

authentication checks, and request reports about email use of the

domain name.Similarly, Public Suffix Operators (PSOs) may do the

same for PSO Controlled Domain Names and non-existent subdomains of

the PSO Controlled Domain Name.

As with SPF and DKIM, DMARC authentication checks result in verdicts

of "pass" or "fail".A DMARC pass verdict requires not only that SPF

or DKIM pass for the message in question, but also that the domain

validated by the SPF or DKIM check is aligned with the RFC5322.From

domain.In the DMARC protocol, two domains are said to be "in

alignment" if they have the same Organizational Domain.

A DMARC pass result indicates only that the RFC5322.From domain has

been authenticated in that message; there is no explicit or implied

value assertion attributed to a message that receives such a verdict.

A mail-receiving organization that performs a DMARC validation check

on inbound mail can choose to use the result and the published

severity of concern expressed by the Domain Owner or PSO for

authentication failures to inform its mail handling decision for that

message.


For a mail-receiving organization supporting DMARC, a message that

passes validation is part of a message stream that is reliably

associated with the Domain Owner and/or any, some, or all of the

Authenticated Identifiers.Therefore, reputation assessment of that

stream by the mail-receiving organization does not need to be

encumbered by accounting for unauthorized use of any domains.A

message that fails this validation cannot reliably be associated with

the Domain Owner's domain and its reputation.

DMARC, in the associated [DMARC-Aggregate-Reporting] and

[DMARC-Failure-Reporting] documents, also describes a reporting

framework in which mail-receiving domains can generate 

[dmarc-ietf] Ticket #113 - DMARCbis -01 Introduction Section

[Todd Herr]

Greetings.

This thread will be used to track discussion of the proposed text for the
Introduction section of draft-ietf-dmarc-dmarcbis-01.

The proposed text was influenced not only by the original text from
draft-ietf-dmarc-dmarcbis-00, but also by tickets 52, 75, 80, 85, 96 and
108. Rather than trying to track changes to the Introduction section
through all six of those tickets, a new one (Ticket 113
) has been opened.

The request from the design team/editors for this ticket is as follows:

If you object to some or all of the proposed text, please communicate the
part(s) to which you object, and propose replacement text for those part(s).

We would like to achieve rough consensus on this section of text by Friday,
May 21.

Current proposed text follows, and side-by-side diffs with version -00 can
be found here



begin current proposed text
---
1. Introduction

   The Sender Policy Framework ([RFC7208]) and DomainKeys Identified

   Mail ([RFC6376]) protocols provide domain-level authentication which

   is not directly associated with the RFC5322.From domain, and DMARC

   builds on those protocols.  Using DMARC, Domain Owners that originate

   email can publish a DNS TXT record with their email authentication

   policies, state their level of concern for mail that fails

   authentication checks, and request reports about email use of the

   domain name.  Similarly, Public Suffix Operators (PSOs) may do the

   same for PSO Controlled Domain Names and non-existent subdomains of

   the PSO Controlled Domain Name.

   As with SPF and DKIM, DMARC authentication checks result in verdicts

   of "pass" or "fail".  A DMARC pass verdict requires not only that SPF

   or DKIM pass for the message in question, but also that the domain

   validated by the SPF or DKIM check is aligned with the RFC5322.From

   domain.  In the DMARC protocol, two domains are said to be "in

   alignment" if they have the same Organizational Domain.

   A DMARC pass result indicates only that the RFC5322.From domain has

   been authenticated in that message; there is no explicit or implied

   value assertion attributed to a message that receives such a verdict.

   A mail-receiving organization that performs a DMARC validation check

   on inbound mail can choose to use the result and the published

   severity of concern expressed by the Domain Owner or PSO for

   authentication failures to inform its mail handling decision for that

   message.


   For a mail-receiving organization supporting DMARC, a message that

   passes validation is part of a message stream that is reliably

   associated with the Domain Owner and/or any, some, or all of the

   Authenticated Identifiers.  Therefore, reputation assessment of that

   stream by the mail-receiving organization does not need to be

   encumbered by accounting for unauthorized use of any domains.  A

   message that fails this validation cannot reliably be associated with

   the Domain Owner's domain and its reputation.

   DMARC, in the associated [DMARC-Aggregate-Reporting] and

   [DMARC-Failure-Reporting] documents, also describes a reporting

   framework in which mail-receiving domains can generate regular

   reports containing data about messages seen that claim to be from

   domains that publish DMARC policies, and send those reports to one or

   more addresses as requested by the Domain Owner's or PSO's DMARC

   policy record.


   Experience with DMARC has revealed some issues of interoperability

   with email in general that require due consideration before

   deployment, particularly with configurations that can cause mail to
   be rejected.  These are discussed in Section 9.
-end current proposed text
---

Thank you for your time.

-- 

*Todd Herr* | Sr. Technical Program Manager
*e:* todd.h...@valimail.com
*m:* 703.220.4153

This email and all data transmitted with it contains confidential and/or
proprietary information intended solely for the use of individual(s)
authorized to receive it. If you are not an intended and authorized
recipient you are hereby notified of any use, disclosure, copying or
distribution of the information included in this transmission is prohibited
and may be unlawful. Please immediately notify the sender by replying to
this email and then delete it from your system.
___
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc