On 5/17/2016 6:08 PM, Murray S. Kucherawy wrote:
On Tue, May 17, 2016 at 5:46 PM, Dave Crocker <[email protected] <mailto:[email protected]>> wrote:Relevant charter text: The working group will explore possible updates and extensions to the specifications in order to address limitations and/or add capabilities. ... Specifications produced by the working group ... 1. Addressing the issues with indirect mail flows The working group will specify mechanisms for reducing or eliminating the DMARC's effects on indirect mail flows, including deployed behaviors of many different intermediaries, such as mailing list managers, automated mailbox forwarding services, and MTAs that perform enhanced message handling that results in message modification. Among the choices for addressing these issues are: - A form of DKIM signature that is better able to survive transit through intermediaries. - Collaborative or passive transitive mechanisms that enable an intermediary to participate in the trust sequence, propagating authentication directly or reporting its results. as against: 2. Reviewing and improving the base DMARC specification The working group will not develop additional mail authentication technologies, but may document authentication requirements that are desirable. Any interesting topic produces real challenges in charter-writing and even more challenges in charter-reading. Indeed, I've yet to encounter a perfect charter. However I read Item 1 as exactly matching the issue at hand and I read that text as being unambiguously perfect for the specific proposal at hand. (Hint: this was not an accident.) The current topic has nothing to do with Item 2, which is where the constraint is placed. So the constraint is not relevant for the current topic. That feels like a convenient interpretation to me, for two reasons: 1) It feels like a bit of a stretch to call ARC "a form of DKIM signature", so I have to assume ARC falls under the second bullet.
You seem to have missed the second sub-bullet under Item 1:
Collaborative or passive transitive mechanisms that enable an intermediary to participate in the trust sequence, propagating authentication directly or reporting its results.
That exactly describes ARC. (Did I mention that that wasn't an accident?)
I'm not opposed to developing ARC within this WG or even within the IETF. I just want to make sure we're following our own rules here, and that someone who later decides he hates ARC has no basis to appeal. If this needs fixing, let's fix it. If nobody really cares, let's move on.
I get that the issue being raised here is purely procedural and that there is no intended (or even actual) resistance to doing the work.
My point is that the points I'm explaining afford a careful reading of the charter and that it shows that the charter /already/ fully covers the proposed work. And not as a stretch.
d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
