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 >> <[email protected]> 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: [email protected] >> >> DKIM-Sig: ... d=beer.com >> From: [email protected] >> >> I believe Patrick defined 2nd party to be: >> DKIM-Sig: ... d=dkim.bar.com >> From: [email protected] >> >> the maawg meeting was a first that I've heard that. >> >> First party is of course: >> >> DKIM-Sig: ... d=bar.com >> From: [email protected] >> >> >> 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" [email protected] 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
