Barry Leiba wrote:
What is ironic about all this DKIM forwarding issue is the same issue
that SPF forwarding had. This was one of the marketing advantages of
DKIM - that it didn't have a forwarding problem.
Well, it does.
Indeed it does. But it doesn't have the forwarding problem for the
(large) class of forwarders that we might rather call "aliases" -- the
ones such as computer.org, acm.org, and college alumni aliases.
That's a major and common case that breaks SPF, but that DKIM works
with.
Unless I don't follow, computer.org does not have a policy record, so
its not really the same issue. Right?
It's also possible -- we'll have to see what happens -- that mailing
lists could change their behaviour to take better advantage of DKIM
(with the specs that are already published). That's not an option
they had with SPF.
No doubt. DKIM/SSP did have a better solution regarding remailers.
That is why people loved it - especially me. But that was when policy
and 3rd party considerations was part of the picture.
For example, you could of had for example, a op=- SSP policy for
computer.org which would allow mipassoc.org to break and resign your mail.
Right now, your domain is spoofable.
In effect, the SPF forwarders problem was carried over to DKIM when we
removed the 3rd party policies. Kludges were developed for SPF and it
appears that might happen with DKIM=ALL now.
So I think the fact that mailing lists aren't straightforward with
respect to any "sender authentication system" doesn't mean that DKIM
hasn't moved us well ahead in this regard.
I agree. I will express as
DKIM + SSP = 4 steps ahead
DKIM + ADSP = 2 steps backwards
We are still 2 step ahead.
<grin>
==
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html