Re: DMARC: perspectives from a listadmin of large open-source lists

Mike,

Thanks for the history lesson. It does seem to highlight somebrokenness in the process, though.


Miles

MH Michael Hammer (5304) wrote:

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(_at_)ietf(_dot_)org] On Behalf Of Miles Fidelman
Sent: Monday, April 14, 2014 11:09 AM
To: ietf(_at_)ietf(_dot_)org
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



--
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra