Subject: [dmarc-ietf] WGLC ARC-16 section 5.2.2 should be stricken

From: Seth Blank <[email-masked]>
Date: Wed, 25 Jul 2018 14:46:44 -0700

https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-16#section-5.2.2

I am confused as to where this section comes from. It was never discussed
on list, and I believe it should be stricken.
https://mailarchive.ietf.org/arch/browse/dmarc/?q=5.7.7 has no results
except for Dave Crocker's document evaluations with comments on the full
text.

At IETF99 and on the list, there was a conversation around handling
tempfails, where the consensus was that we couldn't handle them. That
resulted in the "all failures are permanent" section of the document.
However, other text for handling tempfails showed up, was discussed, and
then removed (
https://mailarchive.ietf.org/arch/msg/dmarc/DmRu-_P-ZtfSjA1k6KUe-Zk0ACY).

---

From: "John R. Levine" <[email-masked]>
Date: 26 Jul 2018 19:36:36 -0400

I agree, this is out of place.  Whether you reject at SMTP time is a much 
broader topic than ARC failures.

> https://mailarchive.ietf.org/arch/msg/dmarc/DmRu-_P-ZtfSjA1k6KUe-Zk0ACY).

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Fri, 27 Jul 2018 06:52:07 -0700

This is not a matter of *whether* you reject during the SMTP interchange as
how to do it in a meaningful way *if* you do so. The discussion about
signaling that the domain authentication failure led to the rejection is
the point of this section.

--Kurt

On Thu, Jul 26, 2018 at 4:36 PM, John R. Levine <[email-masked]> wrote:

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

---

From: "John R. Levine" <[email-masked]>
Date: 27 Jul 2018 10:03:16 -0400

> the point of this section.

Ah.  I still think it should go, but if you really want to do that, invent 
a new enhanced status code.  They're cheap.  5.7.7 isn't right, it's more 
like corrupt S/MIME bodies.

R's,
John

Regards,

---

From: Laura Atkins <[email-masked]>
Date: Fri, 27 Jul 2018 08:01:56 -0700

> On Jul 27, 2018, at 7:03 AM, John R. Levine <[email-masked]> wrote:
> 
> Ah.  I still think it should go, but if you really want to do that, invent a new enhanced status code.  They're cheap.  5.7.7 isn't right, it's more like corrupt S/MIME bodies.

The enhanced status codes are often what ESPs use to make determinations about what to do with future email to that address. Different folks using the same code to mean different make interoperability challenging for bulk senders. If you do want an enhanced status code, pick one that’s not currently being used for something else. Or one that’s rarely used. Continuing to muddy the tar pit doesn’t help anyone. 

IOW, +1 to John’s “invent a new one” 

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: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 27 Jul 2018 10:20:04 -0700

> like corrupt S/MIME bodies.
I did a bunch of these (for DKIM and SPF at least) in RFC7372.  You could
clone the template from there.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 27 Jul 2018 13:41:10 -0400

> clone the template from there.

And if you don't want to make a new one, 5.7.26 (Multiple authentication 
checks failed) seems at least not wrong.  To get to this point DKIM, DMARC, 
and ARC have failed.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Fri, 27 Jul 2018 10:43:53 -0700

> checks failed) seems at least not wrong.  To get to this point DKIM,

Is this better moved into Experimental Considerations?

We could put simple text around if an error code is appropriate or not, and
if so if a new one is needed.

---

From: "John Levine" <[email-masked]>
Date: 27 Jul 2018 17:41:23 -0400

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

Just add the error code.  It's really not a big deal.

R's,
John