On 10/28/2005 08:11 pm, Frank Ellermann wrote: > Stephen Farrell wrote: > > If the above is possible, how should/can it be avoided? > > Never ever sign anything that is already signed. Or at the > very minimum don't "drop" signatures. > > It's the point of DKIM to find some "accountable" party as > near to the sender/originator/author (pick what you like) > as possible. Therefore step 2 in your scenario is strange. > > Why does the list do this, because it manipulated Alice's > mail ? Then Bob's result in step 4 is correct, this mail > was "forged" (= the "list" might be some attacker, social > engineering abusing Alice's address). > > If Alice and Bob insist on using a list that manipulates > mail they have to white list it. Or find a new list admin > with some clue to stop this abuse. > > Step 4 means "DKIM working as designed", it's a feature > and no bug. > Bye, Frank > What Frank said...
I don't think step 5 is inevitable. Organizations shouldn't publish a restrictive SSP without having thought it through. As others have said, perhaps a different sub-domain is an option (but how long until that one is used in fradulent mail instead). No one has invented the perfect technology that will prevent all undersireable behaviors without preventing anything that is desired. All of these have tradeoffs. For many domains the tradeoff between a restrictive SSP and perhaps difficulty getting delivered through mailing lists is a reasonable trade. For others, it's not. On the receiver side, receivers may choose not to reject mail from known mailing lists that fails an SSP check. This is non-trivial for large scale systems, but by no means not doable (per user whitelists are already common at large providers for such things as greylisting, DNSBL checks, and spam filtering). At this point, as the recent message from someone at E-Bay points out, a restrctive SSP has utilility for some domains. That's probably all we need to understand for the moment. Exactly how much granularity, what header fields they bind to, etc. would seem to be work for the working group. Scott K _______________________________________________ ietf-dkim mailing list http://dkim.org
