Subject: [dmarc-ietf] DMARC agenda for the IETF 112 session

From: Barry Leiba <[email-masked]>
Date: Mon, 1 Nov 2021 15:53:11 -0400

I have uploaded a session agenda here:
https://datatracker.ietf.org/meeting/112/session/dmarc

(Direct link to the agenda:
https://datatracker.ietf.org/meeting/112/materials/agenda-112-dmarc )

Barry

---

From: Seth Blank <[email-masked]>
Date: Mon, 1 Nov 2021 13:05:07 -0700

> https://datatracker.ietf.org/meeting/112/materials/agenda-112-dmarc )

I'm ready for item #4; let's keep the other topics concise.

Seth

> Barry
>
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 

*Seth Blank * | Chief Product Officer
*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: Scott Kitterman <[email-masked]>
Date: Mon, 01 Nov 2021 16:44:17 -0400

>From the agenda:

2. Policy Discovery: To walk the tree, not walk the tree, hang from the tree.
   Tracking tickets 24, 34, 46, 58, 59, 60, 68, 108, 111, 112, 121
   Discussion active on the mailing list; we will spend most of the meeting on 
this topic.

My impression is that for policy discovery the group has coalesced around walk 
the tree.  There are open questions regarding how to address alignment in 
light of this.  I think that might be a more fruitful use of meeting time.

Scott K

---

From: Barry Leiba <[email-masked]>
Date: Tue, 2 Nov 2021 08:11:29 -0400

I've tweaked item 2 to make it clear that "this also includes related
alignment issues."

Barry

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 3 Nov 2021 10:22:18 +0100

> https://datatracker.ietf.org/meeting/112/session/dmarc

_ From the agenda:
   3. Bring discussion of indirect email flows to a close.
      Tracking tickets 79, 92, 94, 100, and 122
      We will get to this topic if there's time, but the policy discovery discussion has priority.

Isn't ticket 93 part of indirect mail flows?

IMHO, this topic is important and was lightheartedly considered solved with ARC.  The WG then turned to Phase III.

I ask that a revision of Phase II be scheduled at some later stage rather than closed, because of its importance, especially if Tuesday discussion won't be conclusive on this point.

Best
Ale
--

---

From: Baptiste Carvello <[email-masked]>
Date: Fri, 5 Nov 2021 16:28:21 +0100

Hi,

> DMARC working group IETF 112 agenda
>

if you get to this, and before "closing" this discussion, please
consider the following proposals:

1. (already proposed, but I received no feedback): encourage DMARC
evaluators to make sure no bounce is generated for REJECT when the
message appears to come from a mailing list (silently discarding instead).

Bounces coming in by the thousands are no feedback, but sheer
aggression. The threat of this aggression allows some DMARC implementers
to rely on the mailing list operators to implement workarounds forever
(as Ale among others likes to argue). Which makes bootstrapping any new
solution difficult.

2. (this proposal is new): complement ARC with a secondary DKIM
signature on the first hop.

Under this proposal, a DMARC-implementing domain who wants their
outgoing mail to be possibly involved in indirect mailflow (most senders
do) would appose on each outgoing message a secondary DKIM signature
signing the following headers: the recipient address, in a normalized
form (here, for example: "To: [email-masked]"), From, Date and Message-ID.

Thus the evaluator could make sure that the ARC signing domain has some
relationship with the sender: namely that the sender sent a recent
direct message to this intermediary. This in itself doesn't prove that
the intermediary is trustworthy, but should make the life of fraudsters
sufficiently difficult to deter them in most cases (they would need to
first obtain a genuine message from whoever they try to impersonate).

Cheers,
Baptiste

---

From: Douglas Foster <[email-masked]>
Date: Sat, 6 Nov 2021 09:36:18 -0400

About your proposal to encourage silent discard:   I'm sorry that we have
not provided any feedback.    Feeling ignored or shunned by the group is
worse than having an idea rejected.   For my part, I am a skeptic of your
proposal.

The best outcome would be for the evaluator to perform all operations
before releasing the SMTP session, so that rejection can be handled with an
SMTP result code and extended status code, rather than with a non-delivery
report.   The RFC provides for sessions to remain open a long time so that
this can be done.   If I remember correctly, the rule is 5 minutes to
evaluate MAIL FROM and 10 minutes to evaluate END OF DATA.  I suppose that
many sending systems ignore this rule and timeout more quickly, so really
long evaluation processes run the risk of communication breakdowns.
 Nonetheless, if the evaluation can be completed in one step, you do not
have the flood of non-delivery reports which cause your concern.
Unfortunately, a lot of email configurations use a pipeline process which
makes this behavior difficult to achieve.

I am actually surprised that you have a problem with too many NDRs.   When
I judge a message source to be unwanted or a threat, I don't want to help
them, so I don't currently send NDRs.   Sometimes that is a problem,
because an important correspondent does not realize that an email address
was typed incorrectly so his message was discarded.   But notifying
malicious senders about invalid addresses helps them to do address
harvesting.

For those that do send NDRs, the point of the message is to help both of
you.   If your mailing list message is being blocked because it
fails DMARC, you should do From-rewriting or drop the recipient to fix the
problem.    If I don't want your messages for other reasons, my preferred
outcome is for you to stop sending me unwanted messages.  If your message
is wanted but is being blocked because of a problem that you can fix, my
preferred outcome is for you to fix the problem on your end, so that I
don't have to fix the problem on my end.   You will need an extended status
code to have any hope of knowing what problem to fix on your end.   So it
becomes important for the NDR to include an extended status code.  I
realize that parsing an NDR to obtain useful information is difficult.

I won't be at the meeting.

Doug Foster