First an introduction, I've been active in IETF email and email authentication working groups (As well as in other forums) for quite a number of years but have not been active in IETF from an organizational perspective. I was recently given a heads up about the discussion on the IETF list and joined as well as reviewed the archives related to this discussion. I recognize a number of participants here from other arenas although the majority of participants are not familiar to me. Full disclosure: 1) I represent my organization as a member of DMARC.ORG but I do not speak on behalf of DMARC.ORG; 2) My comments here unless otherwise specifically stated represent my own opinions and are not a statement representing my employer. 3) While I currently moderate various mail lists, I do not administer them from a technical perspective, although I have in the past. I'd like to also provide to a blog post of mine on CircleID from 2009 - http://www.circleid.com/posts/20090414_thoughts_on_future_of_email_authentication/ as well as a response from Dave Crocker - http://www.circleid.com/posts/20090422_thoughts_on_email_authentication_trust/. I believe these are as relevant to the discussion today as they were back then (pre-DMARC). There are not simple issues involved despite some of the pronouncements I've seen and there are not likely to be simple solutions other than local policy ones that work locally. Additional Comments in-line. > -----Original Message----- > From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Miles Fidelman > Sent: Monday, April 14, 2014 11:09 AM > To: ietf@xxxxxxxx > Subject: Re: DMARC: perspectives from a listadmin of large open-source lists > > Doug Barton wrote: > > <snip> > > > > > > But your point is well taken ... the "right" answer may be to fix or > > discard DMARC, I honestly don't know. But in a world where DMARC is > > here to stay, or if not DMARC then some other anti-spam solution that > > breaks mailing list forwarding; and in that same world where mailing > > list traffic is negligible (and therefore the cost of breaking mailing > > lists is in the noise compared to the benefits of deploying said > > anti-spam solution) it's incumbent on the mailing list software folks > > to solve this problem > DMARC has been shown to work extremely well for specific implementations in terms of mitigating direct domain abuse. The DMARC specification was derived from private-channel arrangements between some senders and mailbox providers that started developing in roughly the 2007 timeframe. The impetus for DMARC (and predecessor efforts) was to leverage what was essentially a set of private relationships that were working to create an open standard that would be available for anyone to implement, regardless of size. Mail Lists were identified as a potential issue but the initial set of sending domains did not involve domains with end users and in all of the efforts, this was considered an edge case. My own analysis - for internal consumption within my organization - which dates back to 2004 following the FTC email authentication workshop, the FTC anti-spam workshop and the DKIM "organizational" dinner that followed, was that if email authentication gained any sort of traction in the wild there would be increasing pressure on domains such as ours (greeting cards/social expressions) and Mail Lists, which did not conform to whatever email authentication standards evolved. If we were going to change our practices, I preferred to do so in a planned manner rather than as a result of a change forced by someone else's decision that would force us to react in a short timeframe and under the gun. This was one of the reasons that we changed our organizational practices from spoofing (yes, I know that Dave Crocker objects to this term but until we have a better one that gains a consensus I will continue to use it) to sending mail using our own website domains as of the end of 2007/beginning of 2008 depending on the website domain. > Is it perhaps also incumbent on the folks promulgating DMARC (and its > predecessors, and its sure-to-be successors) to work cooperatively with > mailing list developers, rather than taking the position "nope, we break > mailing lists, not our problem?" > The fact is that a vocal constituency led by John Levine made it extremely clear that MLMs were out of scope and there was zero interest on the part of the MLM community in discussing ways in which MLMs could be made to work in an email authentication framework even if there were any MLM operators willing to do so. His stated solution has been and continues to be that list operators should drop any participants who post from a domain publishing p=reject and to prevent any new participants from joining from a domain that publishes p=reject. The record is quite clear on this and is available to anyone who wishes to peruse email archives, blog posts, etc. I view this as local policy and up to the list operator. I'm not confident how well this will ultimately work for many organizations the operators manage lists for. Just to be clear, the preceding is more of a question than an assertion. This was also a point of contention within the DKIM working group with regard to ADSP and if memory serves me correctly it even came up earlier in the MARID working group as part of the discussion surrounding SenderID and the use of the "Sender" field. I don't intend my statements to lay blame or be pejorative. It is what it is. The folks pursuing email authentication standards and practices publicly noted the potential issues and focused on other areas. It was NOT a position of "nope, we break mailing lists, not our problem?", it was a position of not getting into a painful fight over something that many viewed as an edge case while continuing to pursue the stated email authentication goals. I was personally willing to kick the can down the road and respect the MLM operator position as expressed by John and others. I also note a comment in another IETF thread: Re: "why I quit writing internet standards". The comment is: "For instance, had DMARC proponents and/or Yahoo, spent some time making sure that there was some running code for mailing list use, life would be better." My response is that if the MLM community, as led by John Levine, had expressed an interest (rather than a stone wall effort) in finding ways of making MLMs compatible then there just might have been running code available at an earlier point and yes, life would currently be better. If the position that John has taken and publicly advocated does not represent the MLM developer and operator community position then I'd appreciate folks speaking up because that is the only position which has been communicated - and very stridently. Again, I am NOT advocating that MLM developers and operators must change. I am simply stating that no rational person pursuing email authentication standards and practices development would willingly walk into this buzzsaw absent an expression of interest on the part of MLM developers and operators. > I'm kind of coming to the conclusion that what we need to be looking at is > defining an SMTP extension that addresses BOTH sets of concerns - and > doing so in a cooperative manner that engages not just the community > behind DKIM and DMARC, but also the developers and operators of > mailman, sympa, majordomo, listserv - and ideally the sendmail, postfix, > exim, qmail community. > I don't know whether it is possible to find a solution by modifying current implementation practices or if there is a need for an SMTP extension. Franck Martin has posted in a few places a list of MLMs and how they can work (depending on version, configuration, etc) in a DMARC/email authentication context (I don't believe he has done so here). I have not looked into the specifics of the MLM issue deep enough to make any meaningful comments as to what might be done, if anything. I'm also not interested in getting involved in such an effort if there is a vocal constituency within IETF claiming that any such discussion or effort is an attempt to force MLM developers and operators to change how MLMs function and operate. My personal ox isn't getting gored here and I'm not that much of a masochist that I would choose to engage in such a process under those circumstances. > Dare I suggest that this calls for an IETF working group? > Suggest away but the notion of such a group, unless well wrangled and with a well-defined charter, brings back memories of the MARID working group and its outcome. > Miles Fidelman > Mike