Subject: [dmarc-ietf] is DMARC informational?

From: Michael Thomas <[email-masked]>
Date: Fri, 4 Dec 2020 13:41:28 -0800

Is my google fu completely failing me, or is RFC 7489 not the DMARC 
protocol spec?

If it's informational, how did that happen?

Mike

---

From: Brandon Long <[email-masked]>
Date: Fri, 4 Dec 2020 14:27:57 -0800

The DMARC spec was originally designed by folks outside of IETF, and the
current RFC was a "cleaned up" and modified into RFC format version of that
spec, to match current practice.
There was also concern with the spec's impact on various indirect email.

Hence, informational and independent submission.

This is somewhat spelled out in the working group charter:
https://datatracker.ietf.org/wg/dmarc/about/

Brandon

On Fri, Dec 4, 2020 at 1:41 PM Michael Thomas <[email-masked]> wrote:

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

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 Dec 2020 14:38:51 -0800

On 12/4/20 2:27 PM, Brandon Long wrote:
> The DMARC spec was originally designed by folks outside of IETF, and 
> the current RFC was a "cleaned up" and modified into RFC format 
> version of that spec, to match current practice.
> <https://datatracker.ietf.org/wg/dmarc/about/>
>
That seems really strange because that pretty much describes DKIM as 
well, and it's very standards track. And adsp which dmarc made historic 
was standards track, and certainly had all of the same issues with 
mailing lists, etc.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Fri, 4 Dec 2020 14:42:37 -0800

On 12/4/2020 2:38 PM, Michael Thomas wrote:
> well, and it's very standards track. And adsp which dmarc made 
> historic was standards track, and certainly had all of the same issues 
> with mailing lists, etc. 

DKIM did a version of the same thing, but with less time between 
publishing the non-IETF work and then having a working group to produce 
and IETF version:

https://tools.ietf.org/html/rfc4870

vs.

https://tools.ietf.org/html/rfc4871

Note the Obsoletes value.

> Network Working Group                                          E. Allman
> Request for Comments: 4871                                Sendmail, Inc.
> Obsoletes:4870  <https://tools.ietf.org/html/rfc4870>                                                 J. Callas
> Category: Standards Track                                PGP Corporation
>                                                                 M. Delany
>                                                                 M. Libbey
>                                                                Yahoo! Inc
>                                                                 J. Fenton
>                                                                 M. Thomas
>                                                       Cisco Systems, Inc.
>                                                                  May 2007
>
>                
>
>
>   DomainKeys Identified Mail (DKIM) Signatures
>

-- 
Dave Crocker
[email-masked]
408.329.0791

Volunteer, Silicon Valley Chapter
American Red Cross
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 Dec 2020 14:45:15 -0800

On 12/4/20 2:42 PM, Dave Crocker wrote:
>> historic was standards track, and certainly had all of the same 
>> issues with mailing lists, etc. 
>
> publishing the non-IETF work and then having a working group to 
> produce and IETF version:
>
yes, but the new version was standards track. that's what i'm finding 
surprising.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Fri, 4 Dec 2020 14:48:59 -0800

> yes, but the new version was standards track. that's what i'm finding 

Perhaps you should review the intended status for the current working 
group documents, such as dmarcbis:

https://datatracker.ietf.org/wg/dmarc/documents/

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 Dec 2020 14:51:36 -0800

> https://datatracker.ietf.org/wg/dmarc/documents/
What changed in the bis version to change its intended status?

Mike

---

From: Dave Crocker <[email-masked]>
Date: Fri, 4 Dec 2020 14:59:44 -0800

> What changed in the bis version to change its intended status? 

There is a 'History' button to click on that page, to answer that question.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 4 Dec 2020 15:00:18 -0800

> What changed in the bis version to change its intended status?

The entire point of this working group (and the bis version that is in
progress) is to move DMARC into the fully-recognized "standards" track.
Note that even the current email specs are not "standards" in IETF parlance
(there's another WG addressing that). It's mostly organizational semantic
slicing-and-dicing.

--Kurt

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 Dec 2020 15:01:31 -0800

> There is a 'History' button to click on that page, to answer that 
2020-11-11
	00 	Todd Herr 	New version available: *draft-ietf-dmarc-dmarcbis-00.txt*
2020-11-11
	00 	(System) 	Forced post of submission
2020-11-11
	00 	Todd Herr 	Set submitter to ""Todd M. Herr" 
<[email-masked]>", replaces to (none) and sent approval email to 
group chairs: [email-masked]
2020-11-11
	00 	Todd Herr 	Uploaded new revision

is responsive to my question in what way?

Mike

---

From: Seth Blank <[email-masked]>
Date: Fri, 4 Dec 2020 15:03:21 -0800

https://datatracker.ietf.org/meeting/108/materials/slides-108-dmarc-chairs-slides-00

On Fri, Dec 4, 2020 at 3:01 PM Michael Thomas <[email-masked]> wrote:

> 00 Todd Herr Set submitter to ""Todd M. Herr" <[email-masked]>

-- 

*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: Dave Crocker <[email-masked]>
Date: Fri, 4 Dec 2020 15:04:27 -0800

> is responsive to my question in what way?

You think "the working group created a new document" is not responsive?

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 Dec 2020 15:06:06 -0800

> You think "the working group created a new document" is not responsive?
No.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Fri, 4 Dec 2020 15:06:11 -0800

On 12/4/2020 3:03 PM, Seth Blank wrote:
> <https://datatracker.ietf.org/meeting/108/materials/slides-108-dmarc-chairs-slides-00>

Surprisingly, the wg datatracker page also has a 'Meetings' button.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dave Crocker <[email-masked]>
Date: Fri, 4 Dec 2020 15:06:58 -0800

>> You think "the working group created a new document" is not responsive?

odd.  why not?

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 Dec 2020 15:11:16 -0800

Is it really that hard to summarize why the decision was made and what 
changed in the bis version? I really don't understand this snipe hunt.

Mike

On 12/4/20 3:03 PM, Seth Blank wrote:
> On Fri, Dec 4, 2020 at 3:01 PM Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>>>>     <https://datatracker.ietf.org/wg/dmarc/documents/>
>>>>
>     <[email-masked]> <mailto:[email-masked]>",
>     replaces to (none) and sent approval email to group chairs:
>     [email-masked] <mailto:[email-masked]>
>     2020-11-11
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dmarc>
>
>
>
> -- 
> *Seth Blank*| VP, Standards and New Technologies
> *e:[email-masked] <mailto:[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: Dave Crocker <[email-masked]>
Date: Fri, 4 Dec 2020 15:25:16 -0800

> changed in the bis version? I really don't understand this snipe hunt.

You ask a series of basic question and get a string of responses, which 
point you to easily-found answers, and you call this a practical joke.  
   On the offchance you don't mean one that you've instigated, please 
explain.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 Dec 2020 15:27:44 -0800

On 12/4/20 3:25 PM, Dave Crocker wrote:
>> Is it really that hard to summarize why the decision was made and 
>> what changed in the bis version? I really don't understand this snipe 
>> hunt.
>
>
> You ask a series of basic question and get a string of responses, 
> which point you to easily-found answers, and you call this a practical 
> joke.    On the offchance you don't mean one that you've instigated, 
> please explain.
>
A bunch of non-responsive responses. If you didn't feel like answering 
the question asked you could have just kept scrolling. I didn't ask for 
pointers, after all.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Fri, 4 Dec 2020 15:30:08 -0800

On 12/4/2020 3:27 PM, Michael Thomas wrote:
> the question asked you could have just kept scrolling. I didn't ask 
> for pointers, after all. 

The pointers are answers.  If you don't feel like reading the material 
or reflecting on it, that's a different matter.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Fri, 4 Dec 2020 15:34:49 -0800

On 12/4/20 3:30 PM, Dave Crocker wrote:
>> A bunch of non-responsive responses. If you didn't feel like 
>> answering the question asked you could have just kept scrolling. I 
>> didn't ask for pointers, after all. 
>
There was nothing to "reflect" with the history pointer. It was 
completely non-responsive. If your intention is not to answer the 
question, what is your motivation keeping this non-responsive thread 
alive for a dozen messages?

Mike

---

From: Dave Crocker <[email-masked]>
Date: Fri, 4 Dec 2020 15:42:30 -0800

On 12/4/2020 3:34 PM, Michael Thomas wrote:
>>
>> The pointers are answers.  If you don't feel like reading the 
>> material or reflecting on it, that's a different matter.
>>
> completely non-responsive.

It was completely responsive.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: "Jim Fenton" <[email-masked]>
Date: Sat, 05 Dec 2020 19:33:13 -0800

> (there's another WG addressing that). It's mostly organizational 

The current email specs (specifically RFC 5321 and 5322) are Draft 
Standard, which is part of Standards Track. There is an enormous 
difference between Informational and Standards Track in terms of the 
amount of vetting and consensus required for approval. From RFC 2026:

> An "Informational" specification is published for the general 
> information of the Internet community, and does not represent an 
> Internet community consensus or recommendation.

-Jim

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 6 Dec 2020 13:42:12 +0100

On Sun 06/Dec/2020 04:33:13 +0100 Jim Fenton wrote:
> The current email specs (specifically RFC 5321 and 5322) are Draft Standard, 
> which is part of Standards Track. There is an enormous difference between 
> Informational and Standards Track in terms of the amount of vetting and 
> consensus required for approval. From RFC 2026:
>
>     An "Informational" specification is published for the general information
>     of the Internet community, and does not represent an Internet community
>     consensus or recommendation.

However, discussion and consensus which led to RFC 7489 were not much different 
from the process that is taking place now.  This mailing list started in April 
2013.

Previous discussion took place elsewhere.  There is still a 2011 draft at:
https://dmarc.org/draft-dmarc-base-00-01.txt

Best
Ale
--

---

From: Michael Thomas <[email-masked]>
Date: Sun, 6 Dec 2020 04:46:58 -0800

On 12/6/20 4:42 AM, Alessandro Vesely wrote:
>>> The entire point of this working group (and the bis version that is 
>>> in progress) is to move DMARC into the fully-recognized "standards" 
>>> track. Note that even the current email specs are not "standards" in 
>>> IETF parlance (there's another WG addressing that). It's mostly 
>>> organizational semantic slicing-and-dicing.
>>
>> information
> However, discussion and consensus which led to RFC 7489 were not much 
> different from the process that is taking place now.  This mailing 
> list started in April 2013.
>
And SSP was started in 2004. What's your point?

Mike, i swear it's deja vu all over again

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 6 Dec 2020 14:08:52 +0100

On Sun 06/Dec/2020 13:46:58 +0100 Michael Thomas wrote:
>> different from the process that is taking place now.  This mailing list 
>> started in April 2013.
>>

On chartering the WG in 2013, the decision was made to publish DMARC as 
independent submission, even though it was going to be discussed and reach 
consensus of a IETF WG.  AIUI, that was the original question of this thread.

Best
Ale
--

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 6 Dec 2020 05:57:43 -0800

> consensus of a IETF WG.  AIUI, that was the original question of this

This isn't correct.  DMARC was not published as a product of this working
group.  It was published through the Independent Submission stream, which
can only produce Informational documents.  At the time, this was because
the group advancing DMARC wanted to preserve the installed base and not
cede change control to the IETF, so a working group was not an option.

The working group and the ISE submission started their journies almost at
the same time, but they were procedurally independent.

-MSK, ART AD

---

From: Dave Crocker <[email-masked]>
Date: Sun, 6 Dec 2020 06:06:47 -0800

On 12/6/2020 5:57 AM, Murray S. Kucherawy wrote:
> It was published through the Independent Submission stream, which can 
> only produce Informational documents.

Since this is the IETF and being picky is de rigueur, I'll note that the 
Independent stream also permits Experimental...

You're welcome.  No need to thank me.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Dotzero <[email-masked]>
Date: Sun, 6 Dec 2020 10:13:00 -0500

> cede change control to the IETF, so a working group was not an option.

Murray, your recollection isn't quite accurate. The group advancing DMARC
was looking to preserve the installed base for a defined period of time due
to a) almost all the implementations were custom code and b) there was a
desire to see more experience in the wild as almost all of the deployments
were by members of the group advancing DMARC. There was also a political
element in that there were folks within IETF that felt the DMARC folks were
only looking for a rubber stamp, nothing more. This resulted in part of the
pushback.

> the same time, but they were procedurally independent.

There isn't a whole lot of procedure for ISE. Given the speed of the
working group, in retrospect there wasn't much risk of changes impacting
the installed base for a period much longer than what the DMARC group folks
were looking for. Just saying.

Michael Hammer

---

From: Dave Crocker <[email-masked]>
Date: Sun, 6 Dec 2020 07:23:40 -0800

On 12/6/2020 7:13 AM, Dotzero wrote:
> The group advancing DMARC was looking to preserve the installed base 
> for a defined period of time

Work that comes to the IETF often has a significant history before that, 
often including a well-developed specification and significant installed 
base.

It is not uncommon to publish that pre-IETF specification as an RFC, to 
establish the formal background for the prior work. That's what was done 
for DMARC.

The political -- and, IMO, technical -- issues at the time merely served 
to delay seeking standards track for a revised specification, which is 
what is now being pursued.  While this amount of delay is unusual, the 
sequence is not.

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Sun, 6 Dec 2020 09:06:44 -0800

On 12/6/20 5:57 AM, Murray S. Kucherawy wrote:
> On Sun, Dec 6, 2020 at 5:09 AM Alessandro Vesely <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> This isn't correct.  DMARC was not published as a product of this 
> working group.  It was published through the Independent Submission 
> stream, which can only produce Informational documents.  At the time, 
> this was because the group advancing DMARC wanted to preserve the 
> installed base and not cede change control to the IETF, so a working 
> group was not an option.
>
> The working group and the ISE submission started their journies almost 
> at the same time, but they were procedurally independent.
>

Would that these two responses been the only replies to my question.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Sun, 6 Dec 2020 09:10:25 -0800

On 12/6/2020 5:57 AM, Murray S. Kucherawy wrote:
> DMARC was not published as a product of this working group. 

which, of course, is explicitly noted in the first line of the DMARC RFC:

      "Independent Submission"

and by way of a contrasting example, DKIM:

      "Internet Engineering Task Force (IETF)"

d/

-- 
Dave Crocker
[email-masked]
408.329.0791

---

From: Michael Thomas <[email-masked]>
Date: Sun, 6 Dec 2020 09:20:33 -0800

On 12/6/20 7:13 AM, Dotzero wrote:
>
>
> On Sun, Dec 6, 2020 at 8:58 AM Murray S. Kucherawy 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     working group.  It was published through the Independent
>     Submission stream, which can only produce Informational
>     documents.  At the time, this was because the group advancing
>     DMARC wanted to preserve the installed base and not cede change
>     control to the IETF, so a working group was not an option.
>
>
> Murray, your recollection isn't quite accurate. The group advancing 
> DMARC was looking to preserve the installed base for a defined period 
> of time due to a) almost all the implementations were custom code and 
> b) there was a desire to see more experience in the wild as almost all 
> of the deployments were by members of the group advancing DMARC. There 
> was also a political element in that there were folks within IETF that 
> felt the DMARC folks were only looking for a rubber stamp, nothing 
> more. This resulted in part of the pushback.
>

What I still don't understand is what drove the decision to deviate from 
ADSP. From reading through DMARC, it's basically ADSP nee SSP with 
provisions for SPF and the new reporting feature. SPF had its own policy 
at the time, but adding it and the reporting could have been done in the 
context of an ADSP-bis. Had I been paying attention, I certainly would 
have supported adding both of those features because they clearly make 
getting to the end goal better.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 6 Dec 2020 09:27:30 -0800

On 12/6/20 7:23 AM, Dave Crocker wrote:
> Work that comes to the IETF often has a significant history before 
> that, often including a well-developed specification and significant 
> installed base.
>
> It is not uncommon to publish that pre-IETF specification as an RFC, 
> to establish the formal background for the prior work. That's what was 
> done for DMARC.
>
> The political -- and, IMO, technical -- issues at the time merely 
> served to delay seeking standards track for a revised specification, 
> which is what is now being pursued.  While this amount of delay is 
> unusual, the sequence is not.
>
7 years and counting, 9 years from inception, 12 years from ADSP, and 16 
years from SSP certainly speaks volumes as to why people would prefer to 
avoid sclerotic ietf process. At best, ietf is a discovery mechanism for 
interesting emerging network protocols, not an arbiter of when they are 
actually usable.

Mike

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 6 Dec 2020 20:48:43 -0800

On Sun, Dec 6, 2020 at 9:20 AM Michael Thomas <[email-masked]> wrote:

> provisions for SPF and the new reporting feature. SPF had its own policy at
> the time, but adding it and the reporting could have been done in the
> context of an ADSP-bis. Had I been paying attention, I certainly would have
> supported adding both of those features because they clearly make getting
> to the end goal better.
>

As I recall, people took a run at trying ADSP and it was largely
unsuccessful.  I recall at least Yahoo, PayPal, and Google trying it but
finding that it interfered with their employees' participation in lists, so
they each invented new domains for their employees to use as separate from
their operational public services.  This basically led to its demise.

This might also be because there weren't significant actors pushing for it,
or because it was basically an all-or-nothing prospect, or because its
scope in terms of domain name coverage was too limited.  DMARC was in some
ways a second attempt at ADSP that tried to address those apparent defects.

In addition to reporting, the Organizational Domain, "pct", and "sp" were
considered major features at the time.

-MSK

---

From: "John Levine" <[email-masked]>
Date: 7 Dec 2020 00:18:46 -0500

>their operational public services.  This basically led to its demise.

Among ADSP's shortcomings was that there was no way to test it other
than to turn it on and see how much damage it caused.  The answer was
frequently a lot, so they turned it back off and that was that.

DMARC certainly has its problems but the reporting is great. It makes
the surprises when you turn DMARC on a lot less, at least if your name
is not AOL or Yahoo. 

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Sun, 6 Dec 2020 21:31:05 -0800

> the surprises when you turn DMARC on a lot less, at least if your name

but apparently y! is doing DMARC in the face of its inadequacies anyway. 
i really like the reporting capabilities as an auditing tool as well, 
but it doesn't change much on the ground with the basic problems. it 
just confirms that it's a bad idea to use p=reject in many cases. there 
are clearly many use cases where that isn't a problem -- like bank 
transactional mail -- and ADSP was just fine for that. nothing much has 
changed on that front in 15 years. I find it amusing to be talking about 
this all these years later, with all kinds of companies trying to 
capitalize on the new and mostly unimproved dmarc.

Mike

---

From: "Jim Fenton" <[email-masked]>
Date: Mon, 07 Dec 2020 15:43:40 -0800

On 6 Dec 2020, at 21:18, John Levine wrote:

> In article 
> <[email-masked]> 
> you write:
>

IIRC, Yahoo! And Google had separate domains for their employees well 
before ADSP. Which makes sense, because you want to differentiate your 
employees from your customers. Although I’m not sure that matters 
here.

> the surprises when you turn DMARC on a lot less, at least if your name

Agree, the reporting is great. But so much of the marketing/mandates I 
see around DMARC doesn’t tell domain owners to turn on reporting first 
to see what’s broken, it tells them to publish a DMARC p=reject policy 
because they have a security vulnerability if they don’t. If the 
guidance around DMARC was to publish a p=reject policy only “if it’s 
safe to do so” (meaning mostly for transactional domains), I’d be a 
lot happier with it.

-Jim

---

From: "Dave Warren" <[email-masked]>
Date: Mon, 07 Dec 2020 17:44:54 -0700

On Sun, Dec 6, 2020, at 22:31, Michael Thomas wrote:
> there are clearly many use cases where that isn't a problem -- like bank 
> transactional mail -- and ADSP was just fine for that.

There were still surprises to be had here. I still, to this day, find mail direct from various senders that are wanted by the recipient but that fails SPF without forwarding (with a -all) or hits a dmarc=reject. I quarantine such for review and release to users as needed.

Obviously lots is spam, or forwarding that broke SPF or whatever, but just as often it is a small piece of a big company doing something without fully understanding how modern email works. Oddly it is often security sensitive stuff, not crazy long ago it was Facebook password resets, often it is 2FA codes (which are probably going through a separate channel to get immediate delivery without risking backlog?), and other reasonably important things from parts of the company that I would expect to be at least moderately aware of the email security world.

I agree that ADSP was theoretically fine for this type of use, but in practice, DMARC's feedback simplifies things a lot when a client complains their outbound mail isn't making it and we can quickly see what is being rejected.

it is an imperfect world.

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Dec 2020 16:50:27 -0800

> it is an imperfect world.

I fear that DMARC's reporting only confirmed the obvious: this is hard. 
It gave numbers to anecdotes. That's really useful, don't get me wrong. 
Hopefully it can be used to suss out how to demarcate the long tail of 
don't care use cases.

Mike

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 7 Dec 2020 20:15:25 -0500

A good section of our charter is collection Operational experiences. Doing
an Operational BCP on DMARC based on data collected is what the WG should
do after DMARC-bis.

tim

On Mon, Dec 7, 2020 at 7:50 PM Michael Thomas <[email-masked]> wrote:

> > There were still surprises to be had here. I still, to this day, find
> mail direct from various senders that are wanted by the recipient but that
> fails SPF without forwarding (with a -all) or hits a dmarc=reject. I
> quarantine such for review and release to users as needed.
> >
> > Obviously lots is spam, or forwarding that broke SPF or whatever, but
> just as often it is a small piece of a big company doing something without
> fully understanding how modern email works. Oddly it is often security
> sensitive stuff, not crazy long ago it was Facebook password resets, often
> it is 2FA codes (which are probably going through a separate channel to get
> immediate delivery without risking backlog?), and other reasonably
> important things from parts of the company that I would expect to be at
> least moderately aware of the email security world.
> >
> > I agree that ADSP was theoretically fine for this type of use, but in
> practice, DMARC's feedback simplifies things a lot when a client complains
> their outbound mail isn't making it and we can quickly see what is being
> rejected.
> >

---

From: Michael Thomas <[email-masked]>
Date: Mon, 7 Dec 2020 17:20:35 -0800

On 12/7/20 5:15 PM, Tim Wicinski wrote:
>
> A good section of our charter is collection Operational experiences. 
> Doing an Operational BCP on DMARC based on data collected is what the 
> WG should do after DMARC-bis.

I guess I don't understand why this should be serialized. When I read 
over DMARC I completely recognized ADSP/SSP with the addition of SPF 
policy and reporting. I wouldn't expect a whole lot of changes beyond 
wordsmithing and some nits around the edges. If this is really because 
large mail providers have started using p=reject, that seems to be 
pushing off the actual payload way down the line. Standards track is not 
going to change this much, IMO.

Mike

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 7 Dec 2020 20:27:44 -0500

There are a number of open issues and you open more.
https://trac.ietf.org/trac/dmarc/report/1

I think it is being serialized for lack of people and also WG energy.

tim

On Mon, Dec 7, 2020 at 8:20 PM Michael Thomas <[email-masked]> wrote:

> I guess I don't understand why this should be serialized. When I read over
> DMARC I completely recognized ADSP/SSP with the addition of SPF policy and
> reporting. I wouldn't expect a whole lot of changes beyond wordsmithing and
> some nits around the edges. If this is really because large mail providers
> have started using p=reject, that seems to be pushing off the actual
> payload way down the line. Standards track is not going to change this
> much, IMO.
>
> Mike
>
>

---

From: "John R Levine" <[email-masked]>
Date: 7 Dec 2020 21:25:47 -0500

On Mon, 7 Dec 2020, Jim Fenton wrote:
> Agree, the reporting is great. But so much of the marketing/mandates I see 
> around DMARC doesn’t tell domain owners to turn on reporting first to see 
> what’s broken, it tells them to publish a DMARC p=reject policy because they 
> have a security vulnerability if they don’t. If the guidance around DMARC was 
> to publish a p=reject policy only “if it’s safe to do so” (meaning mostly for 
> transactional domains), I’d be a lot happier with it.

Yes indeed.  It's pretty much the same issue as people who have DMARC on 
a checklist so they publish an SPF record and p=reject, check the item, 
and I'm stuck with mail that disappears when I forward it to its intended 
recipient.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly