Comments in-line From: dmarc [mailto:dmarc-boun...@ietf.org] On Behalf Of Murray S. Kucherawy Sent: Tuesday, May 17, 2016 3:53 PM To: Alessandro Vesely Cc: Kurt Andersen (b); DMARC; Barry Leiba Subject: [!!Mass Mail]Re: [dmarc-ietf] Proposal to adopt ARC documents into the WG (toward phase 2 milestone)
On Tue, May 17, 2016 at 8:08 AM, Alessandro Vesely <ves...@tana.it<mailto:ves...@tana.it>> wrote: > Does anyone object to having the DMARC working group take on this work? I agree with Alessandro, but for procedural reasons: I'm not sure it fits within our present charter. The charter enumerates three tracks, the first of which appears to allow discussion of new protocols; in particular, one might argue that ARC is a "form of DKIM signature that is better able to survive transit through intermediaries". However, in the second track, it says "The working group will not develop additional mail authentication technologies, but may document authentication requirements that are desirable", and there are chunks of ARC that are clearly new. (Having now implemented ARC, I can attest that there was enough new code needed that I would call it "new".) MH: To the extent that ARC informs local policy under DMARC, I support the group taking it on. My personal stance is that p=reject means just that but I recognize that there are folks who can’t get control of their mail streams or there are corner cases such as mailing lists which for historical reasons do not wish to change how they function. Absent a desire to form a distinct working group to develop ARC, I think we need to discuss rechartering before we can entertain this motion. MH: If we need to re-charter then I think we should re-charter. There are already implementations of ARC and there appears to be sufficient support to justify the effort. > Does anyone object to using the two documents above as starting points > for that work? Modulo the first question, no. MH: +1 ARC, as currently documented and conceived, aims at "a more nuanced interpretation to guide any local policies related to messages that arrive with broken domain authentication (DMARC)." It does not propose any DMARC improvement, let alone phase 2 milestone. It proposes to provide a new authentication method that can more accurately reflect the "true" (for some value thereof) authenticity of a message, allowing DMARC to behave more accurately. How is that not an improvement? DMARC was meant to be extensible to better authentication methods as they appear, and this is an instance of such. MH: This is not an extension of DMARC itself. It leverages a DKIM like signing approach to provide additional data points to validators wishing to implement local policy in a more informed manner. This is a nuanced but important difference unless someone is suggesting munging ARC into DMARC itself. Unless ARC commits to a purpose congenial with DMARC's charter, I'd find it objectionable for this WG to take on its work. > Does anyone have an alternative proposal? The "least broken" proposal for phase 2 seems to be dkim-conditional. It emerged as an originator protocol, so it can develop without muddying ARC. I have an unreleased implementation of that. It also more easily qualifies under our charter, IMHO. I think we should at least allow discussion of that one. MH: I thought running code was one of the criteria. Dkim-conditional never got significant support. I’m not against it per se but unless there is a compelling reason I prefer to avoid re-visiting old ground. Mike
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
