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