william(at)elan.net wrote:
On Sat, 15 Oct 2005, Earl Hood wrote:
On October 13, 2005 at 16:20, Jim Fenton wrote:
This relates to one of the motivations for multiple signatures. If you
have a non-mangling mailing list, you might want to preserve the
original signature, because it's still valid and some people might want
to base a decision on that. They (or others) might want to know for
sure that it came from the list, because they want to make sure that
they read all messages on the list. A WG chair might have that
concern,
for example.
And here is where roles can play an important role, especially wrt SSP.
The mailing list signature could not be applied, or be valid, if the
SSP (as currently defined) disallows 3rd-party signatures (and it
has been argued that no entity should allow 3rd-party sigs due to
spoofing concerns).
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.
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. It would need to change the From field to do that. So, in
fact, we are concentrating on visible headers.
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org