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

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:
>>> 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, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> "I dropped the toothpaste", said Tom, crestfallenly.
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> 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