Re: [dmarc-ietf] New DMARC WG, was Re: DKIM through mailing lists (rebutting MLs won't change)
On Friday, May 30, 2014 18:46:45 Steven M Jones wrote: > On 05/30/2014 10:20 AM, Scott Kitterman wrote: > > On Friday, May 30, 2014 17:07:30 Elizabeth Zwicky wrote: > >> On 5/29/14, 8:44 PM, "Scott Kitterman" wrote: > >>> DMARC change is even more off the table than MLM software change > >> > >> DMARC changes are not off the table for Yahoo. ... > > > > Great. Then instead of submitting DMARC as is via a non-IETF process, > > let's have a working group chartered to do that work. > > The Independent Submissions stream is an IETF process. However it does > not involve a working group. No. It's not. That's why it's independent. There's no IETF consensus for Independent Submissions, only a very (by design) limited role for the IESG to do conflict reviews. This may seem like nit picking, but for doing work @ietf.org, it's a quite important one, IMO. Scott K ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
Re: [dmarc-ietf] New DMARC WG, was Re: DKIM through mailing lists (rebutting MLs won't change)
On May 30, 2014, at 6:46 PM, Steven M Jones wrote: > On 05/30/2014 10:20 AM, Scott Kitterman wrote: >> On Friday, May 30, 2014 17:07:30 Elizabeth Zwicky wrote: >>> On 5/29/14, 8:44 PM, "Scott Kitterman" wrote: DMARC change is even more off the table than MLM software change >>> DMARC changes are not off the table for Yahoo. ... >> Great. Then instead of submitting DMARC as is via a non-IETF process, let's >> have a working group chartered to do that work. > > The Independent Submissions stream is an IETF process. However it does > not involve a working group. > > Whether due to too much concern over potentially incompatible changes, > or too much alarm at the language used to try to avoid it, past attempts > to form a working group failed. More than one attempt was made. The > Independent Submission stream was not the first choice. > > I have wanted to see DMARC - and any other necessary protocols - become > the subject of a working group for two years. I hope we can find a way > to make that happen. Dear Steven, I agree with this view. I am confident a fairly effective protocol can allow a DMARC domain to communicate whether another domain forwards their messages. This could be seen as a type of federation similar to how single-sign-on works. Once such abilities have been instantiated between the domain asserting DMARC and the domain enforcing DMARC, nothing else really needs to change. There would be less concern about the negative impact DMARC could have on other email uses. Since this communication would serve a very small faction of overall email traffic from a DNS perspective, DNS should be fine. Results could be cached for 300 seconds or more to improve scaling and at the same time reduce latency. Even then, DMARC feedback would be a minor fraction of email related DNS traffic. Not offering feedback would be analogous to a parent denying the existence of their own children then having them fend for themselves. This attitude burdens receivers lacking knowledge about which exceptions are valid. No other domain should offer these answers. With that said, DNAME would also allow several DMARC domains to select a common feedback zone. It seems this would be close to what John Levine described, except each DMARC domain would be their own trust anchor for all their related email traffic. Regards, Douglas Otis ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] New DMARC WG, was Re: DKIM through mailing lists (rebutting MLs won't change)
On 05/30/2014 10:20 AM, Scott Kitterman wrote: > On Friday, May 30, 2014 17:07:30 Elizabeth Zwicky wrote: >> On 5/29/14, 8:44 PM, "Scott Kitterman" wrote: >>> DMARC change is even more off the table than MLM software change >> DMARC changes are not off the table for Yahoo. ... > Great. Then instead of submitting DMARC as is via a non-IETF process, let's > have a working group chartered to do that work. The Independent Submissions stream is an IETF process. However it does not involve a working group. Whether due to too much concern over potentially incompatible changes, or too much alarm at the language used to try to avoid it, past attempts to form a working group failed. More than one attempt was made. The Independent Submission stream was not the first choice. I have wanted to see DMARC - and any other necessary protocols - become the subject of a working group for two years. I hope we can find a way to make that happen. --S. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
[dmarc-ietf] New DMARC WG, was Re: DKIM through mailing lists (rebutting MLs won't change)
On 05/30/2014 11:28 AM, Stephen J. Turnbull wrote: > Murray S. Kucherawy writes: > > > > DMARC change is even more off the table than MLM software change > > > (which does, as you suggest, evolve over time). > > > > Are there changes people want to make? > > I am of the opinion that the technical DMARC protocols (including > "p=reject") are fine. ... I'm sure that the > probability of technical bugs in the protocols remaining is not zero, > but I imagine they'll be fixed as discovered. Yes, technical bug probability aside, it works well and at scale, and has for more than two years. Speaking strictly for myself, I expected DMARC and/or other specs and practices to evolve such that together they would support more use cases overall. The need to address those areas was well understood and was commented on publicly for quite a while, even if it wasn't adequately documented in the spec. Unfortunately previous activity to establish an IETF working group - where I had thought that evolution would happen - failed. The upshot was that the expected development didn't happen, and DMARC has been effectively static. In the meantime the large scale abuse of email continued to morph, to the point where DMARC was seen as the least harmful option to address a pernicious trend. I would like to see an IETF working group formed, so that we maintain the use cases where DMARC is currently effective and support additional use cases where it currently isn't. > I would like the logical consequences of > unilateral publication of "p=reject" without prior arrangement with > *all* possible relays spelled out. I agree that a solid list of known consequences would be good. And I'm sure it will grow beyond what any of us expect... --Steve. ___ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
