If you use it to allow messages that appear to be FROM somebody on
the CNS list, then it will be exploited by spammers.
My model was down one more level. I was imagining sites "subscribing"
to the service. Thus the service could be used at the SMTP level but
could also be used later.
This is, of course, problematic for the "little guy", the person who
manages one list as a volunteer. There's no easy answer here, although
perhaps a pricing model could be setup that might make this doable.
The real point is that if you're going to be a responsible list owner,
there are things you are going to have to do. You don't have to do
them, of course, but then you don't get to complain when recipients
think you're spam.
What we really need (or perhaps already have and I just don't know
where to find it) is an authenticating mechanism between mail
gateways - something that gets you safely across "untrusted hops"
and into someone's trusted domain.
Can you say "X.400"? What you propose, in my mind, after the addition
of MIME to RFC822 email, was the only other interesting feature
supported by X.400 email that can not be readily duplicated in RFC822
email.
In any case what you propose is conceptually just a decentralization of
the CNS. Instead of centrally knowing who is spam you are requiring the
receiving sites (viz AOL) to keep track of who they are willing to
receive from. Further, the sender now needs to keep a database of the
"magic token" to use on a per receiving site basis.
As implementation this is less backwards compatible than a CNS and I
think it's harder to deploy in a meaningful way. If AOL in particular
agreed to support something like a CNS, there'd be no Catch-22 in
getting started. All it would require is someone to step up and do it.
The only software change with a CNS is to the receiving sites, and even
that is minimal.
Jim
