Subject: [dmarc-ietf] Two new internet-drafts related to forwarded email

From: Kurt Andersen <[email-masked]>
Date: Fri, 16 Oct 2015 07:41:24 -0700

Although not directly submitted to the WG, please take a look at these
drafts and send any comments or feedback to [email-masked] or this
list.

Name:           draft-andersen-arc
> Revision:       00
Title:          Authenticated Received Chain (ARC)
> Document date:  2015-10-16
> Group:          Individual Submission
> Pages:          32
> URL:
> https://www.ietf.org/internet-drafts/draft-andersen-arc-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-andersen-arc/
> Htmlized:       https://tools.ietf.org/html/draft-andersen-arc-00
>
>
> Abstract:
>    Authenticated Received Chain (ARC) permits an organization which is
>    creating or handling email to indicate their involvement with the
>    handling process by adding a cryptographicly signed header (or
>    headers) in a manner analagous to that of DomainKeys Identified Mail
>    (DKIM).  Assertion of responsibility is validated through a
>    cryptographic signature and by querying the Signer's domain directly
>    to retrieve the appropriate public key.  Changes in the message which
>    may break DKIM, may be tracked through the ARC set of headers.
>

and, its accompanying usage recommendations:

Name:           draft-jones-arc-usage
> Revision:       00
> Title:          Recommended Usage of the Authenticated Received Chain (ARC)
> Document date:  2015-10-16
> Group:          Individual Submission
> Pages:          15
> URL:
> https://www.ietf.org/internet-drafts/draft-jones-arc-usage-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-jones-arc-usage/
> Htmlized:       https://tools.ietf.org/html/draft-jones-arc-usage-00
>
>
> Abstract:
>    The Authentication Results Chain (ARC) provides a means to preserve
>    email authentication results and verify the identity of email message
>    handlers, each of which participates by inserting certain headers
>    before passing the message on.  But the specification does not
>    indicate how intermediaries and receivers should interpret or utilize
>    ARC.  This document will provide guidance in these areas.
>

Will look forward to feedback from any interested parties.

--Kurt Andersen

---

From: Tim Draegen <[email-masked]>
Date: Sat, 17 Oct 2015 09:07:17 -0400

> On Oct 16, 2015, at 10:41 AM, Kurt Andersen <[email-masked]> wrote:
> 

Hi Kurt,

Can you and the editors of these documents review the interoperability issues doc (now in WG last call):

  https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-07 <https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-07>

?

Once that's done, maybe the editors of the A.R.C. document can share where it fits into the issues outlined in the interoperability issues doc.

Mainly, though, I'm keening on getting reviews in of the WG doc ASAP.

-= Tim

---

From: Kurt Andersen <[email-masked]>
Date: Sat, 17 Oct 2015 06:11:27 -0700

As one of the editors for the interop document, I have already reviewed it
:-)

The ARC spec is explicitly designed to help preserve authentication results
across multi-hop mail transfers in all of the cases where the
intermediaries participate. I would like to add a section to the interop
document talking about it, but thought that might be presumptuous. If not,
I'll prep an update.

--Kurt

On Sat, Oct 17, 2015 at 6:07 AM, Tim Draegen <[email-masked]> wrote:

>   https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-07
>
> ?
>
> Once that's done, maybe the editors of the A.R.C. document can share where
> it fits into the issues outlined in the interoperability issues doc.
>

---

From: Tim Draegen <[email-masked]>
Date: Sat, 17 Oct 2015 13:00:00 -0400

> On Oct 17, 2015, at 9:11 AM, Kurt Andersen <[email-masked]> wrote:
> 
> As one of the editors for the interop document, I have already reviewed it :-) 

Yes!  I'm hoping your A.R.C. colleagues will chime in, too.

> 
> The ARC spec is explicitly designed to help preserve authentication results across multi-hop mail transfers in all of the cases where the intermediaries participate. I would like to add a section to the interop document talking about it, but thought that might be presumptuous. If not, I'll prep an update.

The word "intermediary" doesn't exist in the current interop issues draft, so if the A.R.C draft is a response to a sub-set of the issues discussed in the interop document, it would be great to explicitly mention which issues are addressed.  This will make it a lot easier to go through once the WG finishes its current task.

Getting the other A.R.C. editors (and perhaps other A.R.C. participants?) to review and comment on the 07 interoperability draft:

..would help this WG finish its current task.  Without review and comment of the documented issues, it will be hard to take seriously any efforts to address said issues.

-= Tim

---

From: Kurt Andersen <[email-masked]>
Date: Sat, 17 Oct 2015 10:25:30 -0700

I'll go through (now that the ARC draft is released) and comment on how if
relates to the interop topology.

--Kurt

On Sat, Oct 17, 2015 at 10:00 AM, Tim Draegen <[email-masked]> wrote:

> The ARC spec is explicitly designed to help preserve authentication
> results across multi-hop mail transfers in all of the cases where the
> The word "intermediary" doesn't exist in the current interop issues draft,
> so if the A.R.C draft is a response to a sub-set of the issues discussed in
> the interop document, it would be great to explicitly mention which issues
> are addressed.  This will make it a lot easier to go through once the WG
> finishes its current task.
>
> Getting the other A.R.C. editors (and perhaps other A.R.C. participants?)
> to review and comment on the 07 interoperability draft:
>
> ..would help this WG finish its current task.  Without review and comment
> of the documented issues, it will be hard to take seriously any efforts to
> address said issues.
>
> -= Tim
>
>
>

---

From: Franck Martin <[email-masked]>
Date: Sat, 17 Oct 2015 22:45:07 -0700

> On Oct 17, 2015, at 6:07 AM, Tim Draegen <[email-masked]> wrote:
> 
>> On Oct 16, 2015, at 10:41 AM, Kurt Andersen <[email-masked] <mailto:[email-masked]>> wrote:
>> 

If an update is needed before next IETF meeting, this has to happen before this Monday 2015-10-19 UTC 23:59.

---

From: Terry Zink <[email-masked]>
Date: Mon, 19 Oct 2015 03:28:14 +0000

The idea behind ARC is similar to the idea behind John Levine's Conditional DKIM but it does it in a different way. Suppose the path is like this:

A --> B --> C

C sees that the message comes "from" A originally but can't verify either A's SPF or DKIM. However, B (who sent the message to C) says "I verified A's SPF and DKIM and it was fine." C then accepts what B said.

That's it in a nutshell (removing the finer points of reputation, how C can trust B, etc.).

-- Terry

From: dmarc [mailto:[email-masked]] On Behalf Of Tim Draegen
Sent: Saturday, October 17, 2015 10:00 AM
To: Kurt Andersen
Cc: [email-masked]
Subject: Re: [dmarc-ietf] Two new internet-drafts related to forwarded email

On Oct 17, 2015, at 9:11 AM, Kurt Andersen <[email-masked]<mailto:[email-masked]>> wrote:

-= Tim

---

From: Steve Atkins <[email-masked]>
Date: Sat, 31 Oct 2015 09:28:16 -0700

> On Oct 18, 2015, at 8:28 PM, Terry Zink <[email-masked]> wrote:
> 
> The idea behind ARC is similar to the idea behind John Levine’s Conditional DKIM but it does it in a different way. Suppose the path is like this:
>  

I've seen this explanation a couple of times now. It only just occurred to me that the reason it's hard to make sense of is because it's using wingdings as a font, so people on Windows systems (might) see arrows where I see an a-grave. You might want to fall back to ascii art, Terry. :)

> A à B à C
>  
> C sees that the message comes “from” A originally but can’t verify either A’s SPF or DKIM. However, B (who sent the message to C) says “I verified A’s SPF and DKIM and it was fine.” C then accepts what B said.
>  
> That’s it in a nutshell (removing the finer points of reputation, how C can trust B, etc.).
>  

Cheers,
  Steve

---

From: Hector Santos <[email-masked]>
Date: Sat, 31 Oct 2015 12:39:08 -0400

> I've seen this explanation a couple of times now. It only just occurred to me that the reason it's hard to make sense of is because it's using wingdings as a font, so people on Windows systems (mig…

LOL, there is more of this going on. I keep blaming myself for not 
taking the time to correct/update/reprogram my mail readers.   It 
seems no one has got WYSIWYG straight these days!

-- 
HLS