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

["John R Levine" <[e-mail]>]

>> Um, didn't we just have this argument last week?
> ...
>> Executive summary: if there's going to be a DMARC group, it gets to
>> work on all the DMARC documents.
>
> Why?
>
> More specifically:
>
>     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, [e-mail], Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.