I agree that we need to answer what problem we are solving before
focusing too heavily on implementation concerns. I disagree though with
the statement below about what the problem is, and I think without
resolving that issue first it is probably not possible to decide how
significant a problem forwarders and mailing lists are
Let's step back and ask what the purpose of this signature is.
The purpose of the mailsig mechanism is:
Provide an assertion of message transit origination
accountability that can be validated.
The use of this accountability is during message
reception,
to assess likely acceptability.
I would suggest a different assertion but the same use of the mechanism.
I would say that the mailsig mechanism
Provides an assertion that the domain of the message author
(2822.From) authorized the sending of a specific message.
The assertion should remain verifiable regardless of original
transmission source (2822.Sender regardless of who that is if they are
in fact authorized), and (this is the most slippery part) as long as the
author of the message remains the same.
We are not trying to replicate pgp or s/mime. We are trying to serve
an entirely different purpose.
I agree with this statement.
We are trying to say who is
responsible for injecting this message into the message transfer
service.
I disagree here.
I consider a valid signature that is based on the 2822 From
address to be more valuable than another one applied later because
it signs the address that I will be looking at in my MUA;
There is no automatic requirement that the recipient user see anything
about the signature.
Really.
I would actually go one step further here and say that it is a specific
goal that the output of the mailsig mechanism is transparent to any MUA
that has not been specifically designed to know what to do with it. For
most normal users (the ones, as receivers, most in need of this kind of
protection) attachments they do not recognize or extra unrecognizable
text in the body of a message makes the message appear less trustworthy
rather than more.
Robert