On Fri, 2004-10-29 at 12:54 -0600, Robert Barclay wrote:
1) As suggested by Dave Crocker both in his initial draft charter and in
the recent discussion about mailing lists
" The purpose of the mailsig mechanism is:
Provide an assertion of message transit origination
accountability that can be validated. "
2) As I suggested a few times earlier
The purpose of the mailsig mechanism is to
Provide an assertion that the domain of the message author
(2822.From) authorized the sending of a specific message.
I'm increasingly of the opinion that the latter of these makes no sense.
It's far more error-prone to use RFC2822 identities, and the only real
excuse for doing it is that the address in the From: header is what's
_visible_ to the user.
But part of the problem with using RFC2822 identities is that you
actually have to deal with the existence of the Sender: and
Resent-{From,Sender:} headers, which often aren't visible anyway. In
fact, even the email address in the From: header isn't reliably
displayed in a coherent form by MUAs.
The other reason I discount the 'visibility' argument for using RFC2822
identities is that by the time the incoming mail is actually somewhere
visible like in my inbox, it's too _late_. The source address, even if
it's authenticated, is going to be one of the least relevant criteria in
my judgement as to whether it's spam or not. The fact that it's offering
methods by which I can enlarge my manhood is probably more of a
giveaway.
Using RFC2821 addresses makes life a _whole_ lot easier. We're not
trying to re-invent S/MIME or PGP. There are perfectly good solutions
for proper signing of outgoing email already; that's not why we're here.
Some other questions that similarly impact the evaluation of the various
proposals as well as the language of the charter:
1) Is this result of mailsig validation intended to be displayed to
MUAs? If so to existing MUAs or only to new MUAs designed to understand
the results
IMHO no. As I said, by the time you're _looking_ at the mail in question
the game is already lost.
2) Alternately is it a goal that the mailsig mechanism be transparent to
the existing email infrastructure
IMHO yes. At least, it should be transparent in as much as existing MUAs
must not show anything different or confusing to the user because the
sender started signing mail with this mechanism.
3) How high a priority is it to be able reject email based on a failed
signature validation?
This is absolutely required. Without the facility to reject mail with
close to 100% certainty that it's really bogus, the whole thing would be
pointless as far as I'm concerned. That's why any RFC2822-based solution
_must_ deal with the majority of existing mailing lists, and why I think
an RFC2821-based solution is probably the sanest approach.
--
dwmw2