Subject: [dmarc-ietf] Round Two: Ticket #66 (Define What It Means to Have Implemented DMARC) and #62 (Reporting a MUST)

From: Todd Herr <[email-masked]>
Date: Tue, 7 Sep 2021 15:16:18 -0400

Greetings.

Previous discussion of this issue a couple of weeks ago seemed to land on
the idea that the text in Section 8 of the current rev of the draft, titled
"Minimum Implementations", was problematic in its content and there was a
suggestion that perhaps the text could be softened and moved to a summary
section.

I'm writing today to seek guidance from the working group as to what such a
summary section might be.

At first blush, it might seem that the current Section 9, "Other Topics",
might be a place for a summary discussion of "Minimum Implementations";
however, the introductory text for Section 9 currently reads "This section
discusses some topics regarding choices made in the development of DMARC,
largely to commit the history to record." and so "Minimum Implementations"
might not fit.

Another choice might be to leave "Minimum Implementations" as a standalone
section, but soften the language, particularly in regards to removing
reporting as a MUST and addressing John and Ale's concerns about requiring
the p= value to be other than none, along with other concerns raised.

A third option might come from consensus from the group, rejecting either
of the two options I've proposed above but instead landing on a new one.

Thank you for your time, and I look forward to your input.

-- 

*Todd Herr* | Technical Director, Standards and Ecosystem
*e:* [email-masked]
*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.

---

From: Douglas Foster <[email-masked]>
Date: Thu, 9 Sep 2021 22:36:28 -0400

For evaluators, the implementation discussion could be structured by the
degree of information shared with senders:

- No sharing
Recipient uses DMARC for its own disposition decisions only.   Scope
elements include:
 Ability to process a PSL on a recurring basis
 Ability to apply DMARC policy to a message to determine sender-recommended
disposition
 Ability to configure local policies to override sender disposition when
desired.

- Limited sharing:  Recipient returns SMTP extended status codes related to
sender authentication.

- Basic Feedback:   Recipient sends RUA reports.  Scope elements include
  Extended parsing of messages
  Database to collect message data
  Report generator to process message data
  Delivery system to post report data to email
  Tools to purge database of obsolete information

- Extended Feedback:  Recipient is also able to send RUF reports when these
are determined to be appropriate.

On Tue, Sep 7, 2021 at 3:16 PM Todd Herr <todd.herr=
[email-masked]> wrote:

> I'm writing today to seek guidance from the working group as to what such
> a summary section might be.
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 09 Sep 2021 23:55:55 -0400

> Thank you for your time, and I look forward to your input.

I've just reviewed section 8 and I find it an odd thing for an IETF document.  
I also find the notion that since my domain has a p=None policy due to the fact 
that an extremely large fraction of the email I send fails DMARC due it being 
sent to email lists translating to "I'm not doing DMARC" to be extremely 
problematic.

As I understand it, it is not typical IETF practice to do conformance 
specifications.  The IETF practice is to define requirements for 
interoperability.

I think that the whole section should just go.  It's not the IETF's job to 
specify contractual requirements for DMARC implementation.  The requirements 
for this should be defined by the entity levying the requirements.  Here's an 
example excerpted from a publicly available source:

> For a domain used to send email: Registrants must publish a DMARC record
> with a reject mail receiver policy (p=reject), except during the
> implementation phase of email as described below*.

...

> *When deploying DMARC during the implementation phase of email capabilities,
> Registrants may temporarily use a “none” (p=none) or “quarantine”
> (p=quarantine) mail receiver policy, but must change the policy to reject
> for ongoing operations within 90 days of deployment.

I know that contracts are routinely written that just say "Implement RFC 
NNNN", but that is not really what RFCs are for and I don't think we should go 
down this path.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 10 Sep 2021 13:01:06 +0200

> - Limited sharing:  Recipient returns SMTP extended status codes related to 

For those who don't use extended status codes, would it make sense to require 
the text "DMARC" in the responses that reject according to that policy?

Best
Ale
--

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 10 Sep 2021 08:10:38 -0400

Thanks for pointing this out Scott, I've been sidetracked.

Section 8 gives me issues also. Many of these topics I've always felt would
go into a BCP on operation practices.

I am not well ensconced in the Mail community, but are this disagreements
between
vendors, software, etc over if one is "implementing DMARC"?

---

From: Dotzero <[email-masked]>
Date: Fri, 10 Sep 2021 09:47:34 -0400

> example excerpted from a publicly available source:

This +1! This proposed section is not about interoperability. Dump it.

Michael Hammer

---

From: "John Levine" <[email-masked]>
Date: 10 Sep 2021 14:48:29 -0400

It appears that Tim Wicinski  <[email-masked]> said:
>between vendors, software, etc over if one is "implementing DMARC"?

Sure, but it's not our problem.  People still have arguments about whether
you've really implemented SMTP if you use a DNSBL to reject some of the traffic.

R's,
John

PS: In case it's not obvious I concur with the advice to take the section out.

---

From: Douglas Foster <[email-masked]>
Date: Sun, 12 Sep 2021 07:55:21 -0400

I am not concerned about defining an acceptable DMARC implementation, but I
am concerned about making implementations successful.,    My four-way
partition is a framework for talking about the obstacles to success:

- Domain owners have trouble knowing whether they are ready for p=reject
because they only get feedback from evaluators that do RUA reporting.

- Extended status codes open an independent communication channel from
evaluator to sending system operator.   The sending system operator may be
independent of the domain owner (mailing list, ESP, forwarding service), or
may operate largely independent of the domain owner (John's "Holy Roman
Empire" organization.)

Ergo:
- We need to explicitly encourage the use of extended status codes.
 Messages that are blocked for DMARC FAIL, but lack an extended status
code, are useless for helping a domain owner fix his problems.

- The current IANA registration should be modified to allow extended status
codes for authentication failure even for accepted messages.   These serve
as warnings to the sending system operators.   This adds no risk.   The
deliberate impersonator knows that his messages will fail sender
authentication, so his interest is whether his message is accepted or not.
 Telling him that I noticed his missing credentials, but allowed the
message anyway, causes no harm.   Telling the same thing to a legitimate
sender gives him a warning to fix the problem.

- We need to encourage people to become RUA reporters, but we cannot
mandate it.   Evaluators will do whatever they want.

How do we sell this in the document, and where?