Re: [dmarc-ietf] Proposing an extension to DMARC to optionally require SPF and DKIM

[Scott Kitterman <[e-mail]>]

On Tuesday, April 02, 2013 04:44:27 AM J. Gomez wrote:
> On Tuesday, April 02, 2013 4:22 AM [GMT+1=CET], MH Michael Hammer (5304) 
wrote:
> > DMARC is not particularly new. The private implementations date back
> > to the 2007 timeframe. The goal of creating a public standard based
> > on the successes seen in the private channel implementations was
> > intended to open it up from a private club with limited membership to
> > something that anyone could implement.
> 
> So, you want the public to aknowledge a private practice as a public
> standard, and at the same time you don't want input from the public but
> blind adhesion, because, you know, it has been working fine in our private
> club?

It was private in 2007.  It's been public for quite some time.  There is, in 
fact, already an open source, high quality C library and milter that supports 
DMARC:

http://www.trusteddomain.org/opendmarc.html

I'm running it in production (and I was not part of that private club) and I 
know others are too.  This may be new to you, but there's an experience base 
built around the current spec and some momentum towards deployment.  

Considering that many of the largest mail providers in the world are among the 
implementers, it's more than just a small private club.

> > Trying to overload other
> > design parameters to attempt to solve something that DMARC
> > intentionally did not try to solve is a dangerous path to go down.
> 
> Terry's proposed extension is:
> 
> 1. Optional,
> 2. Non-default, and
> 3. Not more relaxed but more strict.
> 
> Where is the danger? You don't have the need?, well then go with the more
> relaxed default.
> > I use shared IPs across domains
> > but I DKIM sign those domains and each of the domains has similar
> > security implementations. So from my perspective it is possible to
> > do.... I've been doing it for years.
> 
> So what? Good for you. The world is wide. One size does not fit all, yada
> yada...
> 
> Again, is the proposed optional extension damaging to DMARC's goals? Are
> DMARC's goals those of a private club, or those of the non-spoofing email
> community at large?

First, consider that DMARC itself is optional.  Now you have an optional add 
on that receivers have to consider.  By complicating the deployment decision 
making process, more choices and options slow things down.  That doesn't mean 
they are always to be avoided, but they have a cost.

Second, consider what the deployed receiver base of this option to an option 
is likely to be?  It's zero now.  What sender would rely on it when no 
receiver processes it?  The other way around too.  Getting past this 
chicken/egg problem is hard.  The DMARC folks have spent years working on it.

Third, if an extension like the one you propose has value, it can be added 
later.  There's no need for it to be included in the initial round of 
discussions/standardization of DMARC.  As long as the DMARC record structure 
is extensible to support new policy types (I haven't checked and I don't 
remember) then this can be done later.

If you want to get this to work, focus on making sure the base protocol is 
extensible to do what you want and then work on developing interest and 
momentem around code and deployment to support it.

If you want to change things, that's how to get it done.  It's WAY harder than 
writing emails to IETF lists.

Scott K