On Sun, 2004-09-19 at 22:48 -0700, Jim Fenton wrote:
While it would be a good for mailing lists to sign their outgoing
messages, I don't think we can expect that will happen with all lists
on Day One. In cases where it's possible for user signatures to be
made to work through mailing lists, we can live with those mailing
lists being a little slower to adopt message signing. It's also a
stronger statement if the user signature as well as the mailing list
signature verifies correctly -- we can then attribute the message to
the original sender and not just to the mailing list.
Question: If we _don't_ want multiple signatures, why are we doing this
at the RFC2822 level instead of just using the reverse-path? One other
potential solution to the problem of messages getting munged is to
observe that the worst offenders also change the reverse-path. So we
could tie our signature to our own RFC2821.MailFrom and not _care_ about
mailing lists and the need for permissiveness.
In practice, some canonicalization helps the original user signatures
get through. For example, how many people have noticed that this
mailing lists adds an extra CRLF at the beginning of the body? I
think the benefit of getting intact signatures through such lists
outweighs the likely abuses of such a scheme.
I agree. Especially if we keep a strict distinction between
canonicalisation and permissiveness. Canonicalisation is by definition
always harmless. The policy of precisely what kind of additions to
permit can be per-site and doesn't have to be defined in an RFC.
The idea that all MUA's would have to change to deal with displaying
multiple signed parts in different colors, as well as noting parts whose
signature doesn't validate does not bode well for adoption.
Right. I vote for requiring no MUA modifications at initial deployment.
Absolutely agreed. I was pointing that out as an extra benefit which
could perhaps come later -- not as something which would require
immediate support.
--
dwmw2