Subject: [dmarc-ietf] Last call for WG comments on "Interoperability Issues Between DMARC and Indirect Email Flows"

From: Tim Draegen <[email-masked]>
Date: Tue, 29 Sep 2015 10:34:44 -0400

Hi All,

The editing team deems this draft as ready for last call review.  Here are the links to the recently posted v07:

> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dmarc-interoperability/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-dmarc-interoperability-07
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dmarc-interoperability-07

=- Tim

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 30 Sep 2015 11:13:32 +0200

On Tue 29/Sep/2015 16:34:44 +0200 Tim Draegen wrote: 
> 
> The editing team deems this draft as ready for last call review.

Section 4.2 mentions dkim-conditional.  (IMHO, the latter should be named
draft-dmarc-dkim-conditional.)  Both Section 4.2:

      This DKIM
      signature would come with the condition that a subsequent known
      domain fully DKIM sign the message.

 and Section 4 of dkim-conditional:

   A sender that expects a message to be forwarded might put both a
   conventional DKIM signature and a signature with a !fs tag that
   refers to the domain name of the expected forwarder.

 require conventional, full DKIM signatures.  Why?  It seems to me that any
DMARC authentication method could suffice.  That is, the author domain (!fs
signer) could be SPF authenticated by the MLM; and the MLM could be SPF
authenticated by list recipients.  No?

In case the !fs signature is missing, it may be handy to have the resender
issue a forensic report.  That way, a sender could automatically set up its
signing daemon to add a tag "!fs=mlm.example" to mail destined to, say,
"[email-masked]", where the latter address is extracted from that report.

jm2c
Ale

---

From: "John Levine" <[email-masked]>
Date: 30 Sep 2015 14:42:19 -0000

>authenticated by list recipients.  No?

You're mixing levels here.  dkim-conditional describes a new way to
create a valid DKIM signature.  I wouldn't want to try to describe how
a DKIM validator is supposed to stop and take a detour through an SPF
validator to decide what to do next.

R's,
John

PS: the draft looks fine to me

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 30 Sep 2015 16:48:03 +0200 (CEST)

Hi, Tim,

on Sep 7th, I sent a short review of -05, see https://www.ietf.org/mail-archive/web/dmarc/current/msg02942.html. I didn't see any response, the paragraph I suggested to remove (par. 3.2.5) is still present in -07. Can anyone comment on the suggestion to move section 3.2.5 to some (future) BCP document?

/rolf

----- Original Message -----
> From: "Tim Draegen" <[email-masked]>
> To: "dmarc" <[email-masked]>
> Sent: Tuesday, September 29, 2015 4:34:44 PM
> Subject: [dmarc-ietf] Last call for WG comments on "Interoperability Issues Between DMARC and Indirect Email Flows"
> 
> Hi All,
> 
> Here are the links to the recently posted v07:
> 
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

---

From: Franck Martin <[email-masked]>
Date: Wed, 30 Sep 2015 13:26:24 -0500 (CDT)

----- Original Message -----
> From: "Rolf E. Sonneveld" <[email-masked]>
> To: "Tim Draegen" <[email-masked]>
> Cc: "dmarc" <[email-masked]>
> Sent: Wednesday, September 30, 2015 7:48:03 AM
> Subject: Re: [dmarc-ietf] Last call for WG comments on "Interoperability Issues Between DMARC and Indirect Email
> Flows"
> 
> Hi, Tim,
> 
> on Sep 7th, I sent a short review of -05, see
> https://www.ietf.org/mail-archive/web/dmarc/current/msg02942.html. I didn't
> see any response, the paragraph I suggested to remove (par. 3.2.5) is still
> present in -07. Can anyone comment on the suggestion to move section 3.2.5
> to some (future) BCP document?
> 

I don't like to remove stuff that is still useful, and as I did not see any support for the removal to an hypothetical future BCP...

But I'm happy to do a revision.