Re: [ietf-dkim] DKIM+ADSP = FAIL, and it's our fault

On Sep 15, 2010, at 8:30 AM, McDowell, Brett wrote:

> On Sep 15, 2010, at 11:02 AM, Jeff Macdonald wrote:
>
> > On Wed, Sep 15, 2010 at 10:43 AM, McDowell, Brett
> > <bmcdowell(_at_)paypal-inc(_dot_)com> wrote:
> > > On Sep 15, 2010, at 12:11 AM, Murray S. Kucherawy wrote:
> > >
> > > > Based on that (rather precise) description, aren't ADSP's requirements a 
> > > > proper subset of the DKIM requirements?  If so, I'm not sure I agree with 
> > > > "badly conflicting", but it does frame future discussion quite nicely.
> > > >
> > > > For example, if DKIM enables the identification of mail streams, isn't the 
> > > > one ADSP covers just a specific instance of a mail stream?
> > > BTW, one thing I think we can agree on and find value from in these 
> > > pre-deployment email discussions is terminology.  I ran into a problem at 
> > > the last MAAWG during a panel discussion where my understanding of 
> > > "3rd-party signature" is what someone else meant by "2nd-party signature".  
> > > What is the real definitions of "1st-party", "2nd-party" and "3rd-party" 
> > > signatures in the context of DKIM and ADSP, i.e. in the context of i= and 
> > > d= and from: values?
There is none in the context of DKIM, as DKIM doesn't say much about the 
RFC-822 From:.

> > I believe only the ADSP documents talk about 3rd party, and it is
> > defined as d= not From Domain.
> >
> > These are 3rd party:
> >
> > DKIM-Sig: ... d=dkim.bar.com
> > From: foo(_at_)bar(_dot_)com
> >
> > DKIM-Sig: ... d=beer.com
> > From: foo(_at_)bar(_dot_)com
> >
> > I believe Patrick defined 2nd party to be:
> > DKIM-Sig: ... d=dkim.bar.com
> > From: foo(_at_)bar(_dot_)com
> >
> > the maawg meeting was a first that I've heard that.
> >
> > First party is of course:
> >
> > DKIM-Sig: ... d=bar.com
> > From: foo(_at_)bar(_dot_)com
> >
> >
> > BUT I really thinking making such distinctions is the wrong approach.
> > It really doesn't matter what type of signature it is. I'd even
> > advocate for a DKIM update that would cause all signatures to be 2nd
> > or 3rd to enforce the point.
> That seems aligned with Steve's point about DKIM's value coming (only?) when 
> the d= value is not the same as the domain-name in the from: field.  So 
> according to you (and Steve?) the IETF should pass a normative requirement 
> that all verified email be hired out to 3rd parties?!  That strikes me as 
> very anti-Internet.
I think you're not reading carefully, and you're twisting Jeff's words and mine 
to a point that bears no resemblance to what either of us said.

Note that "d=dkim.bar.com" (or, more realistically, "d=transactional.bar.com") 
are very plausible d= values that someone sending mail "from" 
foo(_at_)bar(_dot_)com may use.

A big part of the value of DKIM is that you can use different d= values for 
mail from the same RFC-822 From: address. That includes d= values that are 
controlled by the sender as well as d= values controlled by others.

As an example, Paypal sends both transactional email, spam and normal employee 
email. The transactional email and employee mail is wanted by recipients. The 
spam is hated by recipients. The reputation of the three mail streams will be 
very different, and you'll want to keep them separated as much as possible so 
that the spam doesn't affect the delivery of the transactional messages too 
badly.

So you may well sign the spam with just "d=bulk.paypal.com", while you'd sign 
the employee mail with "d=corp.paypal.com". And the transactional - you might 
sign it with both "d=transactional.paypal.com" and (hypothetically) 
"d=thismailistransactional.andwanted.andtheypaidus.returnpath.com".

None of those are "first-party" signatures, as the ADSP docs describe it. But 
the strength isn't that they're *not* "d=paypal.com" or "d=bar.com". The 
strength is that they don't *have* to be. Because they don't have to be, it 
allows you to use different d= values using domains you control to 
differentiate the mail streams.

Note that if you want to use ADSP for both the spam and the transactional mail 
you send from the RFC-822 From: of paypal.com you'd need to sign them both with 
"d=paypal.com". That means that those two mail streams would share the 
reputation of that d= field, and your transactional mail would risk being 
blocked due to the spam you send.

(There are some obvious fixes that could be applied to ADSP to reduce that 
problem, but I'll leave that as an exercise for a different thread).

Cheers,
  Steve


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html