Sorry for all the quoting but if I start snipping context and sense will be lost.
>-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Siegel, Ellen >Sent: Wednesday, January 23, 2008 2:37 PM >To: Jim Fenton >Cc: [email protected] >Subject: RE: [ietf-dkim] Seriously. > > > >> -----Original Message----- >> From: Jim Fenton [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, January 23, 2008 10:12 AM >> To: Siegel, Ellen >> Cc: [email protected] >> Subject: Re: [ietf-dkim] Seriously. >> >> Siegel, Ellen wrote: >> > >> > If you have an authentic claim of responsibility from a trustworthy >> party (as per #1), why should it matter whether that party is >represented >> by the From: header or the Sender: header? And why, if the >authenticated >> party in the Sender: field is trustworthy, should it be required that >the >> From: domain is authenticated directly? >> > >> > This all seems counter to the idea that reputation is the real >> differentiator. You seem to be saying that a trustworthy, >authenticated >> signature related to the Sender field is worthless, but any >authenticated >> signature related to the From: field is goodness. Taking that to its >> logical conclusion, spam signed with a signature based on the bogus >From: >> domain will be rated better than valid mail signed with a well-know, >> trusted 3rd party signature based on the Sender field. >> > >> >> The SSP result is by no means the final judgment on a message; >> regardless of the SSP result, a recipient is free to ignore that and >> accept the message anyway. But when you say things like "well-known" >> and "trusted" you're implying some sort of accreditation or >reputation, >> even if that reputation is locally held (i.e., a white list). >> >> SSP is about providing advice in the absence of sufficient trust to >just >> accept/deliver the message. How much is "sufficient" is up to the >> receiver, and may depend on the claimed author. > >I'm glad to hear you say this. I think you may be assuming >that this is self-evident to people reading and/or >implementing the spec, but I'd suggest that it's much less >self-evident than you may believe. At a minimum, I think that >this intent should be made much more clear within the spec itself. > >In fact, the following excerpt from the SSP spec seems to >contradict your statement above: > > In the absence of a valid DKIM signature on behalf of the "From" > address [RFC2822], the verifier of a message MUST determine whether > messages from that sender are expected to be signed, and what > signatures are acceptable. > >There's nothing here about "in the absence of sufficient trust >to just accept/deliver the message"... it's pretty clear that >the check MUST be made if there is no valid signature on >behalf of the FROM address. > >From my reading, I would assert that it is logical that the check MUST be made if there is no valid signature on behalf of the from address. To do otherwise invites abuse. You may not abuse it in your case but others certainly will in other cases. >In addition, the following strongly implies that any signature >from a domain other than the Originator/From domain is >inherently invalid: > > In contrast, this > specification focuses on information which is relevant in >the absence > of a valid signature. > >I think it's important to make a clear distinction between a >blanket statement about validity of the signature, and a >statement about whether or not that signature conveys >information about the policies of the Originator domain. > >[Note too that legitimate services that send emails with From: >domains outside their control are generally very careful to >establish through a confirmation step that such addresses are >under the control of the email author, so there's also a >distinction between the policies of the domain owner and the >policies of individual users within that domain.] > With regard to your bracketed comment, if the issue were only legitimate services then there wouldn't be a need for DKIM at all. Further, there can be no distinction - as you assert - between the policies of the domain owner and the policies of the individual account users within that domain. In order for the concept of domain ownership and administration to make sense, the use of the account by the account user at any given domain has to be considered governed by the policies (whether publicly asserted or not)of the domain owner. If the domain owner asserts a policy, whether through DKIM, SPF or anything else, it has to be presumed that any use outside that assertion is not done so with the approval of the domain owner. A receiver may choose to ignore the domain owners assertion but then again, a receiver may choose to do wahtever they want regardless. > >I'd also note that the text in Section 2.8 under Suspicious >implies again that signatures other than Valid Originator >Signatures are invalid under SSP. I realize that the clause is >an e.g. and not an i.e., but it would take a pretty careful >reader to catch that distinction: > > Messages that do not contain a valid Originator Signature and which > are inconsistent with a Sender Signing Practices check (e.g., are > received without a Valid Signature and the sender's signing >practices > indicate all messages from the entity are signed) are referred to as > "Suspicious". > >And again, in Section 3: > > Verifiers checking messages that do not have at least one valid > Originator Signature MUST perform a Sender Signing >Practices check on > the domain specified by the Originator Address as described in > Section 4.4. > >Seems to me that if you believe that reputation is primary and >SSP is an option available to verifiers who want to dig >deeper, then many of these MUSTs should become MAYs. The >protocol should define how someone who wants to perform the >check can access and interpret the record, but it should not >be defining when they should make the check or what they >should be doing with the information they get back: those >should both be at the discretion of the receiver/verifier. > > To say that receivers purporting to use DKIM don't have to perform a check for SSP if there is not a valid originator signature guts the whole notion of SSP. Why even have SSP if the expectation is that receivers aren't going to check the purported originator if there is no originator signature. > > >> >> > Using SSP as a backup if your first-level reputation check yields >> uncertain results is one thing, but claiming that receivers should >> automatically be invoking it any time that a signature fails to match >the >> originator domain (independently of the trust status of the existing >> signature) seems like it's potentially creating more problems than >it's >> solving. >> > >> >> This is a fair point. We need some words that don't create a >normative >> dependency on reputation and accreditation systems that are out of >> scope. Suggestions welcomed. > >Well, as above, I'd start by taking out directives as to when >a verifier MUST query the SSP record, and as to what it MUST >do with the results. >It seems to me that that decision is wholly at the discretion >of the receiver/verifier, and should be keyed at least in part >off of the reputation that receiver assigns to any valid >signatures that do exist. >I also don't think it's important to describe the source of >that reputation (i.e., it shouldn't be necessary to create a >dependency on any particular reputation/accreditation engine >in order to make the point). > So question for you Ellen - or anyone else (and not meant to be snarky)..... If my company/organization chooses to assert that ALL email sent from ag.com will be signed using DKIM and we use a strong assertion for SPF (or anything else), are you really willing to argue that your company should have the right to send mail purporting to be from ag.com (in the From field) because an individual approached you to mail for them? What if my company does it for their well known brands (which we are working on now)? I would think that you would want to check the policy assertions of the domain in question before you even attempt to send on behalf of that address. In the absence of an assertion (through whatever means, including SSP) by a domain owner then I see no conflict with a 3rd party sending/signing for an individual account user. In the event of a domain making a strong assertion per the standard it would be foolish of the standard not to require receivers to make such a check. To do otherwise defeats the notion of a strong/strict assertion. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
