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

["MH Michael Hammer (5304)" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of J. Gomez
> Sent: Monday, April 01, 2013 10:44 PM
> To: [e-mail]
> Subject: Re: [dmarc-ietf] Proposing an extension to DMARC to optionally
> require SPF and DKIM
> 
> 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?
> 

Not at all. What I'm saying is that DMARC is something that has been working for some time - both in private channels AND as a public standard ( but not an IETF standard). I'm not asking for blind adherence but that proposed additions, extensions and changes should be looked at very carefully as to whether they are generally useful or a corner case which are currently addressed in other ways. In this case I would argue that the proposed change is intended to mitigate architectural and implementation choices that have long been known within the email authentication and reputation community to be problematical.  Shared IPs = shared consequences for the entities sharing those IPs. If you don't want the shared consequences then don't publish SPF and DKIM sign only. When it comes to entities emitting spam, the "we're good people who oopsie, did a bad thing" is what I call the Jessica Rabbit theory of responsibility - "I'm not bad, I'm just drawn that way." 

> > 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.
> 
For example, you are asking existing implementers (validators) to make changes to their code base to accommodate this. The current mailbox coverage of existing validators is 60%+. That is certainly a non-trivial amount of implementation. You ignore the issue of whether validators feel the juice is worth the squeeze for this change. If you make this optional for validators then senders (that implement this extension) will get inconsistent outcomes across mailbox providers. One of the design parameters for DMARC was to minimize this risk. Or are you arguing it should be optional for senders but mandatory for validators? Getting mailbox providers to buy into DMARC and agree to things like reporting (for example) was non-trivial. Be careful of the demands you put on them or you may find DMARC as dead as ADSP.

If you want a DKIM pass only then the simple solution is to DKIM sign (DMARC aligned) and don't publish an SPF record. Done. You are DMARC compliant, no architectural changes are required in the spec and all you have to do is remove your SPF record(s). DMARC validators don't have to do a thing and your stated need is accommodated.

> > 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...
> 

Is yada yada a technical term or simply your way of indicating you watch Seinfeld? There are lots of sizes of implementers that have addressed this issue. You obviously have no interest in existing working implementations (multiple alternatives have been offered by others as well as myself) in this problem space so why would you expect people to give credence to something which has no implementation track record? What I'm hearing is "Shiny new thing I want". These issues have been presented on at any number of venues including MAAWG, RSA, INTERACT, OTA and INTERACT to name a few.

Shared IPs are choice.
Open Relays are a choice.
People make choices and those choices have tradeoffs.

> 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?
> 

I view it as damaging because it requires validators to work to accommodate the change when the same (desired by you) outcome can be achieved without requiring code changes. I view it s not fully baked because the individuals supporting it have not presented data points based on real traffic as to a) the incremental cases and benefits vs additional overhead. For example, what impact, if any, does this have on reporting?

> Regards,
> 
> J. Gomez