Subject: [dmarc-ietf] DMARC bis: revisiting ticket 66

From: Seth Blank <[email-masked]>
Date: Wed, 23 Sep 2020 14:49:35 -0700

As Chairs, we'd like to push for more discussion of this topic.

I've heard some discussion that this distinction belongs in a BCP, not the
base spec, but regardless of where text lands (and it certainly shouldn't
be normative language) the Chairs strongly believe that having rough
consensus on clear definitions is key to progressing the bis effort
effectively. We strongly agree with Dave Crocker's position here:
https://mailarchive.ietf.org/arch/msg/dmarc/XXE3r5FUozl6LVohv8rTkn5QG4E/

Original thread:
https://mailarchive.ietf.org/arch/msg/dmarc/8f3AMoQ_7e3i7zEFTTtK-KnDgzI/
Follow up thread from Todd Herr:
https://mailarchive.ietf.org/arch/msg/dmarc/zHti6fc5Rs4SmfMB3jVK_DQnemA/

To repaste the original context for this conversation:

Many different entities participate in DMARC, and to each, there is a
different definition of what is needed to "implement" or participate in
DMARC.

Should the spec be clear about the different participants, and what it
means for each to participate partially and completely?

As a straw man to start conversation (assume this is all wrong):

The domain owner:
    - partially participating: valid record?
    - complete participation: no part of the domain hierarchy can be
spoofed by an unauthenticated sender?

The receiver/MTA:
    - partially participating: validates DMARC?
    - complete participation: validates DMARC and ARC, and sends aggregate
reports?

The intermediary (is this different than a receiver?):
    - partially: validates DMARC?
    - complete participation: validates DMARC and validates and seals ARC?

Seth

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [email-masked]
*p:* 415.273.8818

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 E. Foster" <[email-masked]>
Date: Wed, 23 Sep 2020 22:53:34 -0400

Rather than approaching the topic based on the degree of completeness that has been achieved, I prefer to approach it from the perspective of functional components that should be implemented jointly.   I propose six function groups.   The grouping and the justification for that grouping appear below.

Doug Foster

Sender:  Capabilities required prior to publishing a DMARC policy

- Sender should assume that some recipients may uplift from p=none to p=quarantine or uplift p<100 to p=100.   To minimize the risk of blocked messages, known mail sources should be configured with DKIM signatures before a DMARC policy is published.

- Sender should assume that, on initial implementation, the domain will have some legitimate but not-verifiable messages.   Therefore an rua=address destination must be configured in the policy to become aware of those problems.   Recipients which detect a DMARC policy without any rua=address can assume that the sender is not serious and the policy is not trustworthy.

- Sender should have a process in place for reviewing DMARC reports to detect and correct errors that cause DMARC verification failures.

Sender / Mediator:   Capabilities required for a DMARC-aware outbound gateway

- Sender / Mediator should be aware that transmitting messages which fail DMARC verification could lead to reputation problems, ranging from individual messages being rejected to the source domain's servers being blacklisted.  

- Therefore, outbound traffic should be handled as follows:- Determine whether each message's source domain has a DMARC-enforcing policy.  - If required, implement one of these compliance measures:- Ensure that a valid DKIM signature is present, based on a known-good configuration flow or based on a test verification.- Add a valid DKIM signature if one is not present and a DKIM key is available.- Rewrite the From address to the local domain, and preferably add a DKIM signature for the local domain, so that the message will pass DMARC when it is received.- Reject the message as undeliverable.

Recipient:  Capabilities required for a DMARC-aware incoming gateway.

- Recipient should assume that some legitimate senders will have configuration errors, even if sender policy asks for enforcement.    Any DMARC-enforcing implementation should have an exception mechanism for overriding p=quarantine or p=reject for specific MailFrom + From combinations.

- Recipient should consider that whitelisting a trusted sender is only safe if spoofing risk has been ruled out.   DMARC-verified combinations of Mail>From + From provides the recipient with the spoof-safe information needed to support whitelisting when whitelisting is desired.   Any DMARC-enforcing implementation should allow DMARC verification status to be included in a whitelisting policy rule.

Recipient:   Capabilities required for an incoming gateway with DMARC "rua" reporting

- Incoming gateway must accurately test incoming messages for DMARC policy compliance
- Incoming messages and their DMARC status must be logged into a database that supports reporting.
- An automated process must be in place to parse the database to generate the DMARC "rua" reports on the required schedule.
- An automated submission process must be in place to transmit the generated "rua" reports when they are generated.

Recipient:   Capabilities required for an incoming gateway with DMARC "ruf" reporting

- Incoming gateway must integrate DMARC-policy checking with message threat assessment.
- Incoming gateway must provide configuration mechanism to specify whether or not a specific ruf-requesting domain should actually be given such notices.   The reporting policy will depend on the recipient's perception of the source's good administrative intentions.
- Incoming gateway must provide configuration mechanisms to specify which types of undesired messages will trigger an "ruf" report.
- Incoming gateway must be able to generate and transmit an "ruf" report in a timely manner after a problem message has been received.
- Incoming gateway must provide throttle controls to avoid backscatter from excessive "ruf" reporting.   This must include, but need not be limited to, any throttling rules provided in the DMARC specification.

Sender:  Capabilities required for receiving "ruf" reports

- Sender must provide an "ruf" destination mailbox.
- "ruf" mailbox must be integrated into a security monitoring and alarming environment, so that corrective action begins in a timely manner after an alarm is received.
- "ruf" mailbox management must be prepared to cope with high message rates because an infected account might generate a high rate of objectionable messages, which may in turn generate a high rate of "ruf" reports.

----------------------------------------

From: seth=[email-masked]
Sent: 9/23/20 5:50 PM
To: IETF DMARC WG <[email-masked]>
Subject: [dmarc-ietf] DMARC bis: revisiting ticket 66

I've heard some discussion that this distinction belongs in a BCP, not the base spec, but regardless of where text lands (and it certainly shouldn't be normative language) the Chairs strongly believe that having rough consensus on clear definitions is key to progressing the bis effort effectively. We strongly agree with Dave Crocker's position here: https://mailarchive.ietf.org/arch/msg/dmarc/XXE3r5FUozl6LVohv8rTkn5QG4E/

Original thread: https://mailarchive.ietf.org/arch/msg/dmarc/8f3AMoQ_7e3i7zEFTTtK-KnDgzI/
Follow up thread from Todd Herr: https://mailarchive.ietf.org/arch/msg/dmarc/zHti6fc5Rs4SmfMB3jVK_DQnemA/

Many different entities participate in DMARC, and to each, there is a different definition of what is needed to "implement" or participate in DMARC.

Should the spec be clear about the different participants, and what it means for each to participate partially and completely?

The domain owner:- partially participating: valid record?- complete participation: no part of the domain hierarchy can be spoofed by an unauthenticated sender?

The receiver/MTA:- partially participating: validates DMARC?- complete participation: validates DMARC and ARC, and sends aggregate reports?

The intermediary (is this different than a receiver?):- partially: validates DMARC?- complete participation: validates DMARC and validates and seals ARC?

Seth

--

Seth Blank | VP, Standards and New Technologies
e: [email-masked]
p: 415.273.8818 

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: Steven M Jones <[email-masked]>
Date: Wed, 23 Sep 2020 23:26:01 -0700

On 9/23/20 2:49 PM, Seth Blank wrote:
>
> ... the Chairs strongly believe that having rough consensus on clear 
> definitions is key to progressing the bis effort effectively. We 
> strongly agree with Dave Crocker's position here: 

Role definitions are useful, and indeed several appear in RFC7489 
section 3. (I'm surprised that Report Generator isn't there...)

I think that expanding those definitions _in the RFC_ would be useful to 
provide a stable reference and avoid confusion in related and subsequent 
documents, not to mention our discussions.

> Should the spec be clear about ... what it means for each to 
> participate partially and completely?

This sounds like, "You haven't really implemented DMARC unless you do 
all of X, Y, and Z and do them this way."

We should keep in mind that DMARC is a _cooperative_ endeavor outside 
the protocol evaluation - the Domain Owner _requests_ a particular 
treatment, they cannot coerce it. A Mail Receiver / mailbox provider may 
send reports to enable the Domain Owner to correct authentication 
issues, but they cannot compel it.*

Yet many of the discussions related to ticket 66 on- and off-list appear 
to arise from people thinking that they are entitled to dictate how 
other entities implement and/or use DMARC outside the protocol 
evaluation, and that is a recipe for disappointment. Guidance is 
perfectly reasonable, probably even helpful, but we aren't going to get 
very far with commandments and proscriptions unless the goal is to have 
them ignored.

  -1 to normative language in this sense
  +1 to guidance/suggestions, probably moreso in a BCP

  --S.

* Obviously certain parties _can_ compel behavior (AOL/VZN/Yahoo, 
Google, etc). But that ability wasn't created by DMARC, and such a 
capability will not be conferred in the other direction by DMARC.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 24 Sep 2020 01:33:13 -0700

> https://mailarchive.ietf.org/arch/msg/dmarc/zHti6fc5Rs4SmfMB3jVK_DQnemA/

If you want to ruminate for a while on where such text should land, you're
free to cultivate it in a new individual submission that the WG tracks,
with perhaps no initial intent to ever publish it.

There's also the working group wiki page, on or below which such text could
be maintained: https://trac.ietf.org/trac/dmarc

-MSK

---

From: Laura Atkins <[email-masked]>
Date: Thu, 24 Sep 2020 09:34:35 +0100

> On 23 Sep 2020, at 22:49, Seth Blank <seth=[email-masked]> wrote:
> 
> I've heard some discussion that this distinction belongs in a BCP, not the base spec, but regardless of where text lands (and it certainly shouldn't be normative language) the Chairs strongly believe that having rough consensus on clear definitions is key to progressing the bis effort effectively. We strongly agree with Dave Crocker's position here: https://mailarchive.ietf.org/arch/msg/dmarc/XXE3r5FUozl6LVohv8rTkn5QG4E/ <https://mailarchive.ietf.org/arch/msg/dmarc/XXE3r5FUozl6LVohv8rTkn5QG4E/>
> 
> Original thread: https://mailarchive.ietf.org/arch/msg/dmarc/8f3AMoQ_7e3i7zEFTTtK-KnDgzI/ <https://mailarchive.ietf.org/arch/msg/dmarc/8f3AMoQ_7e3i7zEFTTtK-KnDgzI/>
> Follow up thread from Todd Herr: https://mailarchive.ietf.org/arch/msg/dmarc/zHti6fc5Rs4SmfMB3jVK_DQnemA/ <https://mailarchive.ietf.org/arch/msg/dmarc/zHti6fc5Rs4SmfMB3jVK_DQnemA/>
> 
>     - complete participation: no part of the domain hierarchy can be spoofed by an unauthenticated sender?
> 
> The receiver/MTA:
>     - complete participation: validates DMARC and ARC, and sends aggregate reports?
> 

The service provider / outgoing MTA (think SendGrid or other bulk MTAs)
- partially participating: allows domain owner to verify using DKIM or SPF
- fully participating: allows domain owner to verify using both DKIM and SPF

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
[email-masked]
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog

---

From: "Douglas E. Foster" <[email-masked]>
Date: Thu, 24 Sep 2020 07:14:08 -0400

Steven Jones observes correctly that
"DMARC is a _cooperative_ endeavor"
between the Domain Owner and the Mail Receiver.   This is true once DMARC is operational.   

But before DMARC becomes operational, it is a cooperative effort between the mail system owner and the software developers.    By defining functional groups, I believe IETF can facilitate the development of usable products and facilitate the intelligent purchase of suitable products by organizations that wish to implement DMARC.

As a particularly bad example:  I have access to a product that has a single checkbox for enabling DMARC.    When it is on, messages that do not pass DMARC verification are blocked or quarantined,   When it is off, DMARC is not evaluated.   It provides no ability to test the impact of DMARC evaluation prior to activating the feature.   The logging subsystem is just a capture of the SMTP chatter, so finding all of the DMARC failures would be difficult.   Depending on the reject codes used, it may not even be possible to identify which messages are blocked because of DMARC.   Once found, there is no mechanism for creating exceptions to correct false positives.  There is no configuration of whether SPF evaluation is strict or relaxed.   In short, the implementation is useless in the real world.   But it can be marketed as "implements DMARC" (without outbound reporting), simply because the developers coded something that complies with part of the specification.

---

From: "John Levine" <[email-masked]>
Date: 24 Sep 2020 12:52:09 -0400

Personally, I have no interest in defining this stuff but in practice,
there are a lot of places where people are instructed to "implement
DMARC", and it would be nice to encourage them to do more than publish
a lame SPF record and p=reject.

R's,
John

---

From: Dotzero <[email-masked]>
Date: Thu, 24 Sep 2020 14:57:51 -0400

> a lame SPF record and p=reject.

I guess I was under the misimpression that IETF is a technical standards
body, not a marketing organization. Perhaps the working group could come up
with a cute logo and charge people for using it to show their compliance.
Is there another IETF standard that has levels of compliance as a marketing
tool? If organizations or governments instruct people "to implement" DMARC,
I would suggest that the onus is on them to provide better guidance as to
what  they require.

Michael Hammer

---

From: Seth Blank <[email-masked]>
Date: Thu, 24 Sep 2020 12:05:56 -0700

> I would suggest that the onus is on them to provide better guidance as to

This is a ticket about precision. There are multiple actors within the
scope of DMARC, and the document lacks the explicit use cases and
definitions for the interactions to be stated precisely.

If you think the document is clear, say so. In these threads, there seems
to be agreement that it's not terribly clear, and a BCP might help
disambiguate. The Chairs have explicitly asked for rough consensus on this
topic, as having part of these definitions in the base spec will drive
clarity and scope as other changes are made. If we can't define what it
means for each actor to participate in DMARC, how can we possibly write a
coherent and consistent spec?

Seth, as Chair

--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 24 Sep 2020 14:03:38 -0700

> I would suggest that the onus is on them to provide better guidance as to

Sarcasm aside, I agree.  IMHO, the text in the standards track document(s)
shouldn't talk about compliance requirements or participation levels.
Standards documents should just talk about how independent implementations
interoperate, and any security/privacy implications of doing so.

I think talking about the advantages of supporting different optional parts
is fine if you want to encourage it, but I think we should resist any
implication that you're below the bar if you're not doing <some set of
things>.

This follows the spirit set out in RFC 2119 Section 6.

-MSK, hatless

---

From: Seth Blank <[email-masked]>
Date: Mon, 28 Sep 2020 20:47:03 -0700

At a minimum, per Dave's comments here:
https://mailarchive.ietf.org/arch/msg/dmarc/XXE3r5FUozl6LVohv8rTkn5QG4E/ I
still believe there's some clear consistent language that needs to be
agreed upon to drive the appropriate specificity in the document.

I do hear the consensus that a) any depth beyond definitions most likely
belongs in a BCP, and b) any text in this document must be purely
informational.

If we can't make headway on this ticket in the next 48 hours, we'll table
it to progress other tickets and come back to it later.

On Thu, Sep 24, 2020 at 2:04 PM Murray S. Kucherawy <[email-masked]>
wrote:

> I think talking about the advantages of supporting different optional
> parts is fine if you want to encourage it, but I think we should resist any
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

--

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 29 Sep 2020 14:48:52 -0700

On Mon, Sep 28, 2020 at 8:47 PM Seth Blank <seth=
[email-masked]> wrote:

> I still believe there's some clear consistent language that needs to be

+1 about clarifying the terminology and I'd second Steve Jones's point
about defining the terms in the RFC for consistent usage throughout both
the RFC and any usage-related BCPs.

Functionally, I think that we need to break down the actions of a receiver
(whether ultimate or intermediary) a bit more clearly:

   - "validate" = go through the process of determining a DMARC pass
   verdict (or not)
   - "enforce" = take some sort of action on the basis of DMARC results +
   policy (published + local)
   - "report" = send RUA (and possibly RUF) reports

--Kurt