[{"author": "Murray Kucherawy", "text": "

Good afternoon.

", "time": "2023-07-28T19:00:44Z"}, {"author": "Jim Fenton", "text": "

Hi!

", "time": "2023-07-28T19:01:25Z"}, {"author": "Hector Santos", "text": "

Hello

", "time": "2023-07-28T19:02:08Z"}, {"author": "Michael Hammer", "text": "

It leaves out AOL publishing p=reject

", "time": "2023-07-28T19:05:22Z"}, {"author": "Steven Jones", "text": "

Perhaps he feels the later merger into Yarizon covers it.Speak no ill of the dead.

", "time": "2023-07-28T19:07:56Z"}, {"author": "Steven Jones", "text": "

Microsoft is still engaged in a phased introduction of ARC features.

", "time": "2023-07-28T19:08:43Z"}, {"author": "Michael Hammer", "text": "

DMARC was never intended to solve those problems.

", "time": "2023-07-28T19:10:58Z"}, {"author": "Jim Fenton", "text": "

He didn't mention DHS requiring p=reject for US federal agencies

", "time": "2023-07-28T19:11:36Z"}, {"author": "Michael Hammer", "text": "

And this working group was never tasked with solving those problems.

", "time": "2023-07-28T19:11:46Z"}, {"author": "Steven Jones", "text": "

What protocol is scoped to try and solve all impersonation-abuse problems in it's domain?

", "time": "2023-07-28T19:12:16Z"}, {"author": "Steven Jones", "text": "

^ What non-PKI, non-IDM

", "time": "2023-07-28T19:13:06Z"}, {"author": "Jim Fenton", "text": "

OTOH, in 9 years the threat landscape has changed. If Friendly Name attacks, etc have become prominent in that time, we should consider whether the scope of DMARC is sufficient any more.

", "time": "2023-07-28T19:22:50Z"}, {"author": "Michael Hammer", "text": "

+1 Wei

", "time": "2023-07-28T19:26:29Z"}, {"author": "Tero Kivinen", "text": "

Instead of saying p=reject, it should have said p=report...

", "time": "2023-07-28T19:31:13Z"}, {"author": "Michael Hammer", "text": "

?

", "time": "2023-07-28T19:31:24Z"}, {"author": "Murray Kucherawy", "text": "

@Steve: It would be wonderful if MS (or anyone really) came to us with implementation experience and a discussion of what value they think it adds.

", "time": "2023-07-28T19:33:59Z"}, {"author": "Murray Kucherawy", "text": "

(\"it\" = ARC)

", "time": "2023-07-28T19:34:26Z"}, {"author": "Steven Jones", "text": "

Ack (speaking then and now as an observer, not fon behalf of MSFT)

", "time": "2023-07-28T19:34:52Z"}, {"author": "Michael Hammer", "text": "

+1 Murray but also others beyond MS.

", "time": "2023-07-28T19:35:08Z"}, {"author": "Murray Kucherawy", "text": "

Honestly any feedback at all would be valuable.

", "time": "2023-07-28T19:36:58Z"}, {"author": "Murray Kucherawy", "text": "

It's dangling otherwise.

", "time": "2023-07-28T19:37:33Z"}, {"author": "olivier hureau", "text": "

I think we should also take into consideration that Microsoft, from April 10th, will 'Honor the DMARC record policy' by default for their tenant.
\nI know that 9 years is long but should we wait the result of Microsoft's move ?

", "time": "2023-07-28T19:40:34Z"}, {"author": "olivier hureau", "text": "

August*

", "time": "2023-07-28T19:41:12Z"}, {"author": "Nigel Hickson", "text": "

Very interesting re MS

", "time": "2023-07-28T19:41:29Z"}, {"author": "Pete Resnick", "text": "

+1 to Jim Fenton. \"Hiding\" this information is a bad idea.

", "time": "2023-07-28T19:42:07Z"}, {"author": "Murray Kucherawy", "text": "

I've seen Star Trek episodes like this.

", "time": "2023-07-28T19:44:39Z"}, {"author": "Murray Kucherawy", "text": "

Olivier: If it's their tenant, isn't the mail all outbound anyway? What's there to honor?

", "time": "2023-07-28T19:45:42Z"}, {"author": "Jim Fenton", "text": "

@olivier hureau April 10 which year?

", "time": "2023-07-28T19:45:58Z"}, {"author": "olivier hureau", "text": "

August 10, 2023. I did a mistake

", "time": "2023-07-28T19:46:10Z"}, {"author": "Todd Herr", "text": "

@murray MS has announced that they will be honoring p=reject on inbound mail

", "time": "2023-07-28T19:46:21Z"}, {"author": "Jim Fenton", "text": "

thanks

", "time": "2023-07-28T19:46:40Z"}, {"author": "Murray Kucherawy", "text": "

@Todd: OK, but that's a general thing, right? Not specific to their tenants?

", "time": "2023-07-28T19:46:42Z"}, {"author": "Todd Herr", "text": "

re: authentication and spam, third paragraph of the Introduction section says:

\n

\"A DMARC pass indicates only that the RFC5322.From domain has been authenticated for that message. Authentication does not carry an explicit or implicit value assertion about that message or about the Domain Owner. Furthermore, a mail-receiving organization that performs DMARC verification can choose to honor the Domain Owner's requested message handling for authentication failures, but it is not required to do so; it might choose different actions entirely.\"

", "time": "2023-07-28T19:46:51Z"}, {"author": "Pete Resnick", "text": "

(I keep hearing \"Pete equals reject\".)

", "time": "2023-07-28T19:46:52Z"}, {"author": "Todd Herr", "text": "

@murray right

", "time": "2023-07-28T19:46:59Z"}, {"author": "Murray Kucherawy", "text": "

@Pete: I'll add that to my bio.

", "time": "2023-07-28T19:47:17Z"}, {"author": "Michael Hammer", "text": "

In publishing p=reject for the domains at my previous employer (billions of emails sent), we meant reject the ones that failed. There were no user accounts at those domains except abuse desk, customer service, etc. Nothing that went through lists.

", "time": "2023-07-28T19:51:42Z"}, {"author": "Murray Kucherawy", "text": "

You used it right!

", "time": "2023-07-28T19:51:56Z"}, {"author": "Nigel Hickson", "text": "

Is this a private conversation or an adult meeting>

", "time": "2023-07-28T19:54:00Z"}, {"author": "Michael Hammer", "text": "

That horse has bolted the barn.

", "time": "2023-07-28T19:54:07Z"}, {"author": "Murray Kucherawy", "text": "

@Nigel: ?

", "time": "2023-07-28T19:54:35Z"}, {"author": "Michael Hammer", "text": "

p=reject is not for everyone. I have no problem with us stating that.

", "time": "2023-07-28T19:55:50Z"}, {"author": "Murray Kucherawy", "text": "

+1

", "time": "2023-07-28T19:55:59Z"}, {"author": "Murray Kucherawy", "text": "

I think part of the issue is operators that want to use it but can't/shouldn't.

", "time": "2023-07-28T19:56:24Z"}, {"author": "Michael Hammer", "text": "

I also recognize that there are people who will implement it differently than what we state.

", "time": "2023-07-28T19:56:44Z"}, {"author": "Pete Resnick", "text": "

@Steven Jones It would be nice if it were treated as informing of policy instead of causing binary choices, but we have plenty of information that implementers don't implement it that way.

", "time": "2023-07-28T19:56:47Z"}, {"author": "Todd Herr", "text": "

@steve jones and RUF not working due to GDPR and its ilk: Fair

", "time": "2023-07-28T19:57:18Z"}, {"author": "Michael Hammer", "text": "

There are folks using RUF though private (contractual) channels because of the PII issues.

", "time": "2023-07-28T19:58:05Z"}, {"author": "Michael Hammer", "text": "

Asking the recipient to do (not telling)

", "time": "2023-07-28T19:58:57Z"}, {"author": "Murray Kucherawy", "text": "

@Neil: I wish DMARC had that advice before 2013. :)

", "time": "2023-07-28T19:59:21Z"}, {"author": "Michael Hammer", "text": "

MUST py more attention...

", "time": "2023-07-28T19:59:53Z"}, {"author": "Michael Hammer", "text": "

pay

", "time": "2023-07-28T19:59:57Z"}, {"author": "Murray Kucherawy", "text": "

Maybe that's a way out of this.

", "time": "2023-07-28T19:59:59Z"}, {"author": "Michael Hammer", "text": "

@Murray?

", "time": "2023-07-28T20:00:24Z"}, {"author": "Steven Jones", "text": "

+1 to Neil's point about \"I'm telling you I'm authenticating what I send out, act accordingly\"

", "time": "2023-07-28T20:00:25Z"}, {"author": "Murray Kucherawy", "text": "

@Michael: i.e., remove from the protocol the part about signaling what the sender wants you to do. Just leave it as signal that, as Neil said, \"I send all my stuff authenticated. Do what you will.\"

", "time": "2023-07-28T20:01:21Z"}, {"author": "Michael Hammer", "text": "

Ah

", "time": "2023-07-28T20:01:30Z"}, {"author": "Steven Jones", "text": "

@Murray, DMARC did have that advice/meaning, in my recollection/experience. \"I'm authenticating, I found all my sources through reporting using p=none, and I'm on top of my mail operations to keep them authenticated\"

", "time": "2023-07-28T20:01:40Z"}, {"author": "Michael Hammer", "text": "

I'm not sure I believe that is the answer.

", "time": "2023-07-28T20:01:56Z"}, {"author": "Murray Kucherawy", "text": "

DKIM did it right, IMHO: \"You can't rely on the lack of a valid signature to tell you anything. You also can't rely on the presence of a valid signature to tell you that this message is a good message.\"

", "time": "2023-07-28T20:02:05Z"}, {"author": "John Scudder", "text": "

Tourist here but completely agree with Pete\u2019s SHOULD vs MUST characterization.

", "time": "2023-07-28T20:02:28Z"}, {"author": "Murray Kucherawy", "text": "

DMARC went further by saying \"This is safe to reject\", and it's kind of blown up, because that message isn't reliable.

", "time": "2023-07-28T20:02:56Z"}, {"author": "Murray Kucherawy", "text": "

Or people don't use it reliably.

", "time": "2023-07-28T20:03:39Z"}, {"author": "Michael Hammer", "text": "

@Murray, in the original context of DMARC, it was/is reliable.

", "time": "2023-07-28T20:04:09Z"}, {"author": "Murray Kucherawy", "text": "

What's the \"original context\"?

", "time": "2023-07-28T20:04:27Z"}, {"author": "Pete Resnick", "text": "

People are publishing \"p=reject\" when they don't know that their users who send through forwarders are going to get rejected; they are simply told that they should use it and they do. We need to be clear to those folks.

", "time": "2023-07-28T20:04:32Z"}, {"author": "Murray Kucherawy", "text": "

@Pete: +1

", "time": "2023-07-28T20:04:45Z"}, {"author": "Steven Jones", "text": "

@Pete: +1

", "time": "2023-07-28T20:05:14Z"}, {"author": "Jim Fenton", "text": "

@Murray DMARC went further than \"this is safe to reject\", it told recipients to do that. ADSP has \"discardable\" which is much closer to the declarative not imperative sense that @Neil is referring to.

", "time": "2023-07-28T20:05:29Z"}, {"author": "Michael Hammer", "text": "

Financials, other domains like greeting card companies, etc. where there is a very high risk of abuse.

", "time": "2023-07-28T20:05:30Z"}, {"author": "Murray Kucherawy", "text": "

@Jim: Yep.

", "time": "2023-07-28T20:05:41Z"}, {"author": "Murray Kucherawy", "text": "

@Michael: So \"original context\" is non-list non-user use cases?

", "time": "2023-07-28T20:05:55Z"}, {"author": "Pete Resnick", "text": "

If we put in the document, \"p=reject means that you disallow your users to subscribe to mailing lists\", fine. But we are not going to say that, because that was not the original intent.

", "time": "2023-07-28T20:05:57Z"}, {"author": "Michael Hammer", "text": "

For the original intent, there were no users subscribing to mailing lists.

", "time": "2023-07-28T20:06:44Z"}, {"author": "Jim Fenton", "text": "

@Pete also people are publishing p=reject because it turned into a compliance requirement

", "time": "2023-07-28T20:06:51Z"}, {"author": "Murray Kucherawy", "text": "

Right. So would we be fine with adding text that says \"This protocol is not to be used by any domain that might include human users that participate in mailing lists\"?

", "time": "2023-07-28T20:07:24Z"}, {"author": "Murray Kucherawy", "text": "

Which, to me, is what Barry suggested.

", "time": "2023-07-28T20:07:32Z"}, {"author": "Michael Hammer", "text": "

@Jim, agreed. I think it turning into a compliance requirement was a bad thing and inapproprite.

", "time": "2023-07-28T20:07:52Z"}, {"author": "Steven Jones", "text": "

If you go back, I believe the usage advice was not to use p=[quarantine|reject] for domains where regular users sent regular email, and definitely not where they were using lists. If we lost that language/advice, shame on us.

", "time": "2023-07-28T20:08:01Z"}, {"author": "Murray Kucherawy", "text": "

@Jim: Yeah, it's like pouring gas on the problem.

", "time": "2023-07-28T20:08:18Z"}, {"author": "Michael Hammer", "text": "

@Steven, +1

", "time": "2023-07-28T20:08:29Z"}, {"author": "Jim Fenton", "text": "

@Murray If mailing lists were the only problem. Forwarders that break authentication are another one.

", "time": "2023-07-28T20:08:51Z"}, {"author": "Murray Kucherawy", "text": "

@Steven: We may not have actually lost it, but maybe we're not pushing on it hard enough. The pain it causes is perhaps not as front-and-center as it needs to be.

", "time": "2023-07-28T20:09:01Z"}, {"author": "Murray Kucherawy", "text": "

@Jim: True.

", "time": "2023-07-28T20:09:05Z"}, {"author": "Steven Jones", "text": "

(I say \"usage advice\" because I can't cite language/publications interactively here, sorry)

", "time": "2023-07-28T20:09:10Z"}, {"author": "Steven Jones", "text": "

@Neil: ... and then there's the swamp of how a million MUAs will handle the contents of the rfc5322.From header and it's components...

", "time": "2023-07-28T20:10:21Z"}, {"author": "Todd Herr", "text": "

The current definitions of the values of none, quarantine, and reject are as follows:

\n

none:
\nThe Domain Owner offers no expression of preference.
\nquarantine:
\nThe Domain Owner considers such mail to be suspicious. It is possible the mail is valid, although the failure creates a significant concern.
\nreject:
\nThe Domain Owner considers all such failures to be a clear indication that the use of the domain name is not valid. See Section 8.3 for some discussion of SMTP rejection methods and their implications.

\n

We're kinda/sorta part of the way to what Tero has suggested

", "time": "2023-07-28T20:10:33Z"}, {"author": "Michael Hammer", "text": "

NO to using Sender. That brings back the problems of SenderID where you could game it to always get a neutral.

", "time": "2023-07-28T20:10:39Z"}, {"author": "Michael Hammer", "text": "

That adds even more complexity

", "time": "2023-07-28T20:12:01Z"}, {"author": "Steven Jones", "text": "

@Neil: just noting that anything with MUA is daunting, not speaking against your point(s)

", "time": "2023-07-28T20:12:20Z"}, {"author": "Murray Kucherawy", "text": "

If you are going to argue against the idea of a tag indicating which method(s) you want receivers to use, please explain why that's a bad idea.

", "time": "2023-07-28T20:12:53Z"}, {"author": "Pete Resnick", "text": "

@Michael Hammer You only get back to neutral if you follow it blindly, which gets us back to the issue of following p=reject blindly.

", "time": "2023-07-28T20:13:01Z"}, {"author": "Michael Hammer", "text": "

I'm in the queue

", "time": "2023-07-28T20:13:38Z"}, {"author": "Pete Resnick", "text": "

The answer is, \"Use the protocol to say what's actually going on and then don't act blindly.\"

", "time": "2023-07-28T20:13:42Z"}, {"author": "Pete Resnick", "text": "

@Michael Hammer You're in the queue for the SPF discussion.

", "time": "2023-07-28T20:14:27Z"}, {"author": "Murray Kucherawy", "text": "

@Todd: Regarding \"all such failures\", maybe the audience is not sufficiently imaginative to appreciate the breadth of that failure domain.

", "time": "2023-07-28T20:15:04Z"}, {"author": "Pete Resnick", "text": "

+1 to @John Levine

", "time": "2023-07-28T20:15:50Z"}, {"author": "Murray Kucherawy", "text": "

I don't understand the problem with \"auth=both\" since that's what we have today.

", "time": "2023-07-28T20:16:31Z"}, {"author": "Tobias Fiebig", "text": "

agreeing with john here; there is a lot of noise at the tail end of things, esp. in DKIM misconfiguration, so kicking SPF might have a lot of surprise-implications for people with broken DKIM.

", "time": "2023-07-28T20:16:34Z"}, {"author": "Murray Kucherawy", "text": "

Where's the SPF upgrade attack documented?

", "time": "2023-07-28T20:18:23Z"}, {"author": "Jim Fenton", "text": "

@Murray I just looked that up: https://www.valimail.com/blog/how-an-spf-upgrade-attack-spoofed-googles-blue-checkmark/

", "time": "2023-07-28T20:21:08Z"}, {"author": "Steven Jones", "text": "

There was consideration pre-IETF of having more of a matrix approach to policy, \"I only use SPF\" vs. \"I use both\" vs. \"I only use DKIM\" -- it was originally rejected due to concerns about complexity and misconfiguration. Should that be reconsidered 10+ years on?

", "time": "2023-07-28T20:21:36Z"}, {"author": "Murray Kucherawy", "text": "

@Steven: Seems like that's what's being proposed, yes.

", "time": "2023-07-28T20:22:13Z"}, {"author": "Murray Kucherawy", "text": "

@Jim: Thanks.

", "time": "2023-07-28T20:22:20Z"}, {"author": "Tobias Fiebig", "text": "

@olivier hureau can you please let me know where/how it states it wrong?

", "time": "2023-07-28T20:23:10Z"}, {"author": "olivier hureau", "text": "

@Tobias France

", "time": "2023-07-28T20:24:06Z"}, {"author": "Tobias Fiebig", "text": "

@olivier hureau I am pretty sure the usenix paper does not state anything relating France to DMARC.

", "time": "2023-07-28T20:24:40Z"}, {"author": "Tero Kivinen", "text": "

Implementations using SPF on the SMTP time are one of the big problem, as they do not check DKIM, they do not do DMARC, they can't be helped using ARC etc. Unfortunately we can't say anything about them in the DMARC specification, as they are not even implementing DMARC, they are doing SPF badly...

", "time": "2023-07-28T20:25:01Z"}, {"author": "Steven Jones", "text": "

St@ckOverflow > IETF

", "time": "2023-07-28T20:25:03Z"}, {"author": "olivier hureau", "text": "

@Tobias I am not talking about france

", "time": "2023-07-28T20:25:04Z"}, {"author": "olivier hureau", "text": "

@tobias let's go private if you want

", "time": "2023-07-28T20:25:23Z"}, {"author": "Steven Jones", "text": "

To Mike's point re: complexity in policy statements -- the rampant mis-configuration of SPF records was top-of-mind

", "time": "2023-07-28T20:27:02Z"}, {"author": "Tero Kivinen", "text": "

But the good thing is that those people who do SPF on the SMTP phase, do not care what DMARC spec says, so we can still say do not do SPF in DMARC as they are not going follow it anyways :-)

", "time": "2023-07-28T20:28:11Z"}, {"author": "Michael Hammer", "text": "

Thank you

", "time": "2023-07-28T20:29:43Z"}, {"author": "Steven Jones", "text": "

Thank you, everybody!

", "time": "2023-07-28T20:29:54Z"}]