> Imagine the following scenario for the evolution of the Internet and for
> the evolution of legitimate opt-in mailing lists.
>
> Some party (or parties) declares itself to be a sort-of central clearing
> house for information on legitimate mailing lists. Let's just call it
> `legit-lists.org'. That party operates some sort of a server which allows
> other sites to obtain (either via push or via pull, whatever seems to make
> the most sense) a full and current list of legitimate opt-in mailing lists
> _and_ their associated *public encryption keys*. (Now stay with me here.
> It isn't as bad as you think, and I'm *not* going to propose any sort of
> exhorbitantly complex Rube Goldberg mechanism... just something simple
> based upon public-key encryption technology.)
I think the immediate impact of attempting to implement this
proposal, would be that most list owners would start getting
bounces/errors from sites trying to use the whitelist, and drop
all people from those sites from their lists.
There are _a lot_ of mailing lists running a lot of different software.
A fair number are still things like sendmail aliases updated
by hand, or other quick-and-dirty solutions for which it would
be hard to add public key signing.
It might be feasible to get public key signing of list messages
folded into new releases of some list software, expecially if
it conferred some other benfit besides getting past an unimplemented
whitelist. But there would be a sigificant time lag getting it
adopted.
The particular scheme you suggest sounded like it might be possible
for a spammer to subscribe to a real list and re-use its
authetication header on spam, since you are only signing the
Date: header, not the message body. Spammers don't care
if the Date: header is accurate. The typical delays in mail
delivery would force one to accept Date: headers up to
several days old; you could not use as tight a time window
as say, Kerberos.
I think you'd have to sign some a digest of some normalized form of
a selected subset of headers and the message body. Doing it
so that various mail transfer agents will not break the checksums
is non-trivial (there are still things like ASCII/EBCDIC
translation and trimming /wrapping of lines to worry about).
There's also the question ITAR and cyptography; though I think
this can be bypassed if you can use a scheme that can only
be used for signing and not for encryption.
