Subject: [dmarc-ietf] Charter Discussion at the DMARC BOF

From: Russ Housley <[email-masked]>
Date: Fri, 12 Jul 2013 15:53:54 -0400

Dear DMARC Mail List Participants:

I have already posted a Draft Agenda for the DMARC BOF.  That includes a discussion of the draft working group charter.  The closer we can get to consensus on this mail list before the BOF, the more likely that we can get a working group shortly after Berlin.  To this end, I want to start a discussion of the charter.

Trent Adams has agree to lead the discussion of the charter during the BOF, so I am passing him the pen for the draft charter.

Russ

---

From: "J. Trent Adams" <[email-masked]>
Date: Fri, 12 Jul 2013 14:55:10 -0600

As a reminder, here's a link to the most recent version of the proposed
charter:

http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

Any and all comments welcome, the more specific you can be the better.

Thanks,
Trent

On 7/12/13 1:53 PM, Russ Housley wrote:
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc

-- 
J. Trent Adams

Profile: http://www.mediaslate.org/jtrentadams/
LinkedIN: http://www.linkedin.com/in/jtrentadams
Twitter: http://twitter.com/jtrentadams

---

From: "John Levine" <[email-masked]>
Date: 13 Jul 2013 01:36:09 -0000

Um, didn't we just have this argument last week?

Here's a pointer to my proposed charter improvements:

http://www.ietf.org/mail-archive/web/dmarc/current/msg00335.html

Executive summary: if there's going to be a DMARC group, it gets to
work on all the DMARC documents.

R's,
John

---

From: SM <[email-masked]>
Date: Fri, 12 Jul 2013 19:21:36 -0700

Hi Trent,
>http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

   "The existing base specification is being submitted via the
    Independent Submission Editor for publication."

   "For reference, draft-kucherawy-dmarc-base is the current location
    of the base specification, which will be submitted to the
    Independent Submission Editor."

Based on the messages which have been posted to this mailing list I 
think that the submission path mentioned above is incorrect.

  "The working group will review the specification, including its
   limitations, particularly focusing on those listed below."

Is it being suggested that the future working group reviews or does 
not review the base specification?

  "Also in scope are possible extensions enabling accommodation of
   previously unanticipated use cases."

I gather that the group has carefully considered the implications.

  "The initial charter for this working group does not include revising
   the base specification, but rather producing incremental extensions to it."

The answer to the question about working group review of the base 
specification affects the above.

  "At the time of chartering, DMARC has already achieved an estimated
   coverage of 60% of the Internet's mailboxes."

The above text looks like something from the marketing department.

Regards,
-sm

---

From: Dave Crocker <[email-masked]>
Date: Fri, 12 Jul 2013 19:44:24 -0700

> Um, didn't we just have this argument last week?
...
> work on all the DMARC documents.

Why?

More specifically:

      For each such document, what is the... uhhhh... you know... "work"?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John R Levine" <[email-masked]>
Date: 13 Jul 2013 00:43:21 -0400

>     For each such document, what is the... uhhhh... you know... "work"?

Sigh.  Keeping in mind that we DO NOT KNOW what the draft that will 
apparently be submitted says (since the most recent public one is from 
April), here's a few things in that draft that could use work:

* Fix the requirements in sec 3.1

* Fix the terminology in sec 4.

* Figure out whether the public suffix kludge in sec 4 and A.6.1 needs 
further definition to interoperate adequately

* Decide whether to remove section 12.2.2 since I don't think anyone has 
ever implemented and it's rather badly specified.  Every http POST I've 
ever seen has had an application/x-www-form-urlencoded or 
multipart/form-data body.  While there's nothing in the http spec that 
forbids other random multiparts, I wouldn't want to write it into a 
standards track document unless I was confident that web servers would do 
something reasonable.  Note that an http PUT means to replace whatever is 
at the URL with the body of the message, which is not what you want. 
POST makes more sense, but for a POST to work reliably you'd be much 
better off with the gzip file inside a multipart/form-data.  The Subject 
field it describes is also pretty dodgy since I don't know anyone who uses 
them with http, and would in any event be redundant with the filename in 
the form-data.  The section is also somwhat underspecified on the response 
side, since it gives no hint as to what http return codes might be 
returned and how a receiver should interpret them, e.g., if it gets a 302 
should it really go re-post it somewhere else?  If it gets a 4xx should it 
keep sending subsequent reports?

* Has 12.2.4 been implemented?  The bracketed text suggests not.  It says 
that if you can't deliver a report, you sould send a DSN to the same 
address you couldn't deliver the report to, which seems like an exercise 
in futility.

* Section 13 seems to say that if I act as a mail receiver, I have to send 
daily reports, unless that "and/or" means something else.  Say I have a
small mail system where I use a postfix plugin to do DMARC processing on 
inbound mail, but I don't have a database to store all the results so I 
can't send aggregate reports.  It appears to be telling me in that case 
not to bother doing the inbound processing.  That seems counterproductive.

That's what I got in a 15 minute read through.  If I read it carefully, 
I'd probably find more, as would other people.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 13 Jul 2013 01:29:37 -0400

>work on all the DMARC documents.

+1.

Scott K

---

From: Russ Housley <[email-masked]>
Date: Sat, 13 Jul 2013 16:23:43 -0400

John and Scott:

It is clear that there are people on this list that hold this view.  However, that is not the draft charter that Barry has asked us to produce.  Without an indication from Barry that he is not going to AD sponsor the DMARC specification, the charter should not include that as part of the work.

Barry has said that we wants review for the DMARC specification.  However, if the path forward for the DMARC spec does not change, that review will not be the responsibility of the proposed working group.

Russ

---

From: Russ Housley <[email-masked]>
Date: Sat, 13 Jul 2013 16:35:50 -0400

> http://wiki.tools.ietf.org/wg/appsawg/trac/wiki/DMARC

Trent:

I believe that the proposed WG name is dmarc, not dmarcext.

The existing specification is not being submitted to the "Independent Submission Editor for publication."  If this was to happen, it would become an Informational RFC. Instead, Barry is AD sponsoring the document on the standards track.  This has an impact on the text in two places.

I suggest that "initial charter" be replaced with "charter".  This will read better a few months from now.

I find this wording abrasive: "... include developers and operators of DMARC-based mechanisms outside the core set of working group participants in its consensus discussion."  I suggest: "... include developers and operators of DMARC-based mechanisms to the greatest extent possible."

Russ

---

From: "J. Trent Adams" <[email-masked]>
Date: Mon, 15 Jul 2013 09:12:18 -0600

John -

Many thanks for the pointer to the previous conversation. Apologies for
asking again when the answers were already staring up at me from my
inbox. Digging in now.

Thanks again,
Trent

On 7/12/13 10:43 PM, John R Levine wrote:
> * Decide whether to remove section 12.2.2 since I don't think anyone
> has ever implemented and it's rather badly specified. Every http POST
> I've ever seen has had an application/x-www-form-urlencoded or
> standards track document unless I was confident that web servers would
> do something reasonable. Note that an http PUT means to replace
> whatever is at the URL with the body of the message, which is not what
> you want. POST makes more sense, but for a POST to work reliably you'd
> be much better off with the gzip file inside a multipart/form-data.
> The Subject field it describes is also pretty dodgy since I don't know
> anyone who uses them with http, and would in any event be redundant
> with the filename in the form-data. The section is also somwhat
> underspecified on the response side, since it gives no hint as to what
> http return codes might be returned and how a receiver should
> interpret them, e.g., if it gets a 302 should it really go re-post it
> somewhere else? If it gets a 4xx should it keep sending subsequent
> reports?
>
> * Has 12.2.4 been implemented? The bracketed text suggests not. It
> says that if you can't deliver a report, you sould send a DSN to the
> same address you couldn't deliver the report to, which seems like an
> exercise in futility.
>
> * Section 13 seems to say that if I act as a mail receiver, I have to
> send daily reports, unless that "and/or" means something else. Say I
> have a
> small mail system where I use a postfix plugin to do DMARC processing
> on inbound mail, but I don't have a database to store all the results
> so I can't send aggregate reports. It appears to be telling me in that
> case not to bother doing the inbound processing. That seems
> counterproductive.
>

-- 
J. Trent Adams

---

From: Franck Martin <[email-masked]>
Date: Mon, 15 Jul 2013 14:15:54 -0500 (CDT)

----- Original Message -----
> From: "John R Levine" <[email-masked]>
> To: "Dave Crocker" <[email-masked]>
> Cc: [email-masked]
> Sent: Friday, July 12, 2013 9:43:21 PM
> Subject: Re: [dmarc-ietf] Charter Discussion at the DMARC BOF
> 
> 

I believe that netease has implemented it. 

> address you couldn't deliver the report to, which seems like an exercise

There are many reasons why an email will not be delivered, one of these reasons is that the receiver will not accept an aggregate report that it is too big. Notifying that an aggregate report could not be delivered can make sense here and is not an exercise in futility, which brings back that the way to get the report delivered is via http (instead of fragmenting the report into smaller ones and emailing them).

---

From: "John R Levine" <[email-masked]>
Date: 15 Jul 2013 16:08:36 -0400

> There are many reasons why an email will not be delivered, one of these 
> reasons is that the receiver will not accept an aggregate report that it 
> is too big. Notifying that an aggregate report could not be delivered 
> can make sense here and is not an exercise in futility, which brings 
> back that the way to get the report delivered is via http (instead of 
> fragmenting the report into smaller ones and emailing them).

Well, there's an interesting question.  Has anyone implemented the size 
limits on reports?  Has anyone seen one of thees bounce reports for 
oversize messages in the wild?

By the way, I entirely agree that sending reports by http is a reasonable 
idea.  But not the way it's described in the current draft, which doesn't 
even the difference between PUT and POST, or the way that servers expect 
the arguments to POST to be sent.

Regards,