Re: DMARC from the perspective of the listadmin of a bunch of SMALL comm

Ned,

I don't see this as a big technical problem.  The engineering has been 
done. For the most part, not to over simplify, this was a battle 
between two camps:
   DKIM + POLICY (1st party author domain) framework
   DKIM + TRUST (3rd party signer domain) framework

DKIM is a trust model. It was unfortunate, by design, the Policy 
Semantics were pulled.  The trust advocates "won the war" by finally 
making ADSP historic to make room for DMARC where the focus was mostly 
about Reporting.  Even with ADSP, we were collecting information but 
it lacked the reporting part, unlike early versions of the policy 
proposals. But DMARC reporting was richer.
But this DMARC did have a similar handling logic it learned from SSP, 
DSAP and ADSP. It was odd but I presume the IETF believed DMARC 
p=reject will not be used as much as they strongly believed the 
equivalent ADSP dkim=discardable policy would never be used or 
honored, and if so, in a small insignificant way.
YAHOO changed that mindset and reality. Did they ever! In my book, as 
I always knew this lost of policy focus would have to be corrected 
some day.  Yahoo has forced the issue. Policy wins.
To me, both TRUST and POLICY are needed.

POLICY is just a first level filter of the most obvious domain 
practice faults. After policy passes the test, the trust layer comes 
in. After all, for DKIM trust query to be activated, the signature 
must exist and be valid per specification.
But just with using trust, Yahoo could of used the signer domain as 
the DKIM specs wanted it to do in the first place to lookup some 
"trusted" whitelist or 3rd party service to see if the signer domain 
is a "good guy."  It could of also accepted and quarantined the 
message allowing the user to white list the signer domain.  Yahoo 
online mail UI can offer the user a "DKIM whitelist" input field. 
Yahoo can keep this to itself or it can create public ATPS records, if 
it makes sense.
DKIM also has the Agent or User Id (AUID), the i= tag in 
DKIM-signature, that can be used as some MLM signing method.  I think 
we need to explore this again.
But ultimately, the author domain policies should be honored as the 
first layer check before trust can even come into play.  That mindset 
needs to be accepted.
The hard part is going to be getting the same folks to change their 
tune about how the Author Domain fits in with DKIM specification.  The 
DKIM abstract says:
   DKIM separates the question of the identity of
   the Signer of the message from the purported author
   of the message.

Impossible. I always wanted to know which "question" that was. 
5322.From is the sole single technical requirement to be hash bound to 
the signature.  There will always be an authorization relationship.
--
HLS

On 4/17/2014 11:46 AM, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
> > On Apr 16, 2014, at 11:00 PM, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
> > > > On Sat, Apr 12, 2014 at 4:35 PM, <ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com> 
> > > > wrote:
> > > > > The underlying technical issue is that the two technologies DMARC is built
> > > > > on -
> > > > > DKIM and SPF - both attach additional/restrictive semantics to
> > > > > longstanding mail
> > > > > system fields. (Broadly speaking, From: for DKIM and MAIL FROM for SPF.)
> > > > Something's amiss here.  What new semantics does DKIM attach to From:?  As
> > > > far as I know, it only requires that the field be signed.  It doesn't
> > > > require that it be interpreted in a particular way or that it contain any
> > > > particular value.
> > > I was trying to be brief. Yes, I'm well aware that DKIM can be used in other
> > > ways. This entire discussion is within the context of DMARC here. Do you
> > > disagree that DMARC's use of DKIM and SPF assign additional semantics to header
> > > and envelope from fields respectively?
> > Murray is correct. DKIM does not create special From header field semantics.
> Actually, by requiring that the signature cover the From: field, it sort
> of does. But that's beside the point. Again, I was talking about DMARC's
> use of DKIM, not DKIM usage in general.
>
> > However, DMARC semantics are similar to those of ADSP while avoiding some
> > shortcomings.
> But both of them attach additional semantics to From:. (Not that they had
> a choice; as I pointed out previously, in order to acheieve the stated
> goal they have to attach the check to the identity users actually see.)
>
> > ...
> > > > Also: By "the IETF published a draft", are you talking about an RFC, or the
> > > > DMARC base draft?
> > > The draft, of course.
> > >
> > > > It seems extreme to lay blame on the IETF in general
> > > > merely for having an open mechanism by which to post a draft for all to see
> > > > and discuss.  A "Request For Comment", as it were.
> > > You may think it extreme. I don't. I think the IETF's politics have led to  it
> > > inching closer to moral hazard territory for a long time, and with this
> > > incident it has stepped in it.
> > This disruption should be shared with the provider that has already
> > enumerated 30,000 mailing-lists but made no effort to establish a means to
> > verify these sources and to safely assert specific exceptions to DMARC
> > alignment requirements. This ability is desperately needed before applying
> > DMARC reject on user accounts.  I'll be happy to modify either ATP or ATPS to
> > permit these exceptions without the need to alter mailing-list.
> I'm by no means sure that ATP or ATPS is the right answer, but I certainly
> agree that we need to at least try and address the situation that's been
> created.
>
> Sigh. We have a lot of work to do, don't we?
>
>                                 Ned