Subject: [dmarc-ietf] I-D Action: draft-ietf-dmarc-arc-protocol-14.txt

From: [email-masked]
Date: Mon, 23 Apr 2018 20:02:43 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain-based Message Authentication, Reporting & Conformance WG of the IETF.

        Title           : Authenticated Received Chain (ARC) Protocol
        Authors         : Kurt Andersen
                          Brandon Long
                          Steven Jones
                          Seth Blank
                          Murray Kucherawy
	Filename        : draft-ietf-dmarc-arc-protocol-14.txt
	Pages           : 51
	Date            : 2018-04-23

Abstract:
   The Authenticated Received Chain (ARC) protocol creates a mechanism
   whereby a series of handlers of an email message can conduct
   authentication of the email message as it passes among them on the
   way to its destination, and create an attached, authenticated record
   of the status at each step along the handling path, for use by the
   final recipient in making choices about the disposition of the
   message.  Changes in the message that might break existing
   authentication mechanisms can be identified through the ARC Set of
   header fields.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmarc-arc-protocol/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dmarc-arc-protocol-14
https://datatracker.ietf.org/doc/html/draft-ietf-dmarc-arc-protocol-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-14

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Seth Blank <[email-masked]>
Date: Tue, 24 Apr 2018 18:01:11 +0200

This update is an editing pass for readability, clarity, and conciseness.
It also addressed several open items in the issue tracker.

On Tue, Apr 24, 2018 at 5:02 AM, <[email-masked]> wrote:

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

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 24 Apr 2018 21:10:59 +0100

> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-arc-protocol-14

Section 3.3:
  For AMS generation, what is the intention regarding oversigning?

Section 11:
  Additional implementation:

    Organization: Exim developers
    Status of Operation: Operational; requires specific enabling
                         for compile.
    Coverage: Full spec implemented as of [ARC-DRAFT-13]
    Licensing: GPL
    Contact Info: [email-masked]
    Implementation notes:
         - Exim 4.91

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 24 Apr 2018 14:45:46 -0700

>   For AMS generation, what is the intention regarding oversigning?

Can you clarify what you mean by "oversigning"?

>     Contact Info: [email-masked]

ack - will include for the next version (but we're looking to have last
call review on the current one).

--Kurt

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 24 Apr 2018 22:54:32 +0100

> Can you clarify what you mean by "oversigning"?

In DKIM you can, in the signature, list a header more times than
are actually present in the message. If you do, the addition of
another header of that name will break the signature; if you do
not it will not, and could obscure the original (depending on
the receiving MUA choice).

Consider that being done to the Subject: header.

(Any more than degree-one oversigning is pointless)
-- 
Cheers,
  Jeremy

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Tue, 24 Apr 2018 16:32:14 -0700

> Consider that being done to the Subject: header.

I think that you could use the same set of header fields to be oversigned
by AMS as you use for DKIM.

--Kurt