[ietf-dkim] Re: dkim service

[Jim Fenton]

william(at)elan.net wrote:

>
> On Sun, 16 Oct 2005, Jim Fenton wrote:
>
>>> Mail list is "3rd party" for message signature only if it does not 
>>> set Sender field to itself, which most mail lists actually do. If 
>>> mail list does add Sender it can be viewed as "2nd party" to the 
>>> message but I'm
>>> of the opinion that "1st party" signature (i.e. added by original 
>>> message
>>> author as listed in From header field) should survive mail list 
>>> processing
>>> too and is as important as mail list added signature. But I maybe 
>>> looking at it all in the METASIG identity perspective rather then 
>>> the one you're taking with DKIM (which I still don't understand 
>>> because the original goal
>>> of all the work was to stop spoofing of visible headers and is to me 
>>> most important and some here seem to have forgotten it).
>>
>>
>> Have another look at the SSP specification, section 2.1.  The only 
>> time that the Sender field matters at all (and it's extremely rare) 
>> is when the From address contains multiple mailbox specifications.  
>> In that case the Sender field is used as a "tiebreaker", as spelled 
>> out in RFC 2822 section 3.6.2.
>
>
> Is that the same as saying that for purposes of forgery protection 
> (rather then establishing "some" identity for reputation/accreditation 
> by means of the signature) DKIM focuses only on the "From" header field?
>
> [Yes I understand its not 100% only from in case of multiple addresses]

Yes, although I'm reluctant to use the term "forgery" because it means 
different things to different people.  We are not providing a signature 
from the author him/herself, so it could be argued that we aren't 
providing forgery protection at all.

>
>> So even if the mailing list does set the Sender field, it does not 
>> change the fact that the mailing list signature is a third-party 
>> signature.
>
>
> In that case I'd expect that you should try to make sure the signature
> from original sender (ok - from person listed in From) survives cases
> of mail lists and instead I hear some people on this list saying that
> we should not even try.

This is a difficult question, because anything we do to accommodate 
mailing lists introduces new vulnerabilities.  Anything that 
accommodates the addition of ads by mailing lists (since some are 
advertising-supported) also accommodates the addition of undesirable 
content to messages, unless you know exactly who the "good" mailing 
lists are.  Since new mailing lists are being created all the time, it's 
very difficult to know which ones are "good", especially when performing 
verification for an entire domain.

>
>> It would need to change the From field to do that.  So, in fact, we 
>> are concentrating on visible headers.
>
>
> Sender is visible header on nuber of mail clients and definetly on
>
>> 50% of the ones if counted based on actual use by people. Actually
>
> the situation is such that those for who its not visible header field,
> can very often change it to make it visible through some additional 
> seetting and at the same time they are also the ones that are a lot
> less likely to be fooled by forgery in the first place...

The people we're trying to help are the ones who won't can't do that 
additional setting to make Sender visible.  And I'm not satisfied with 
helping 50% of the clients.

-Jim