I've been reading this discussion for a while and I have one core question,
which is why is this an "antispam certificate". At the end of the day,
we've all got a slightly different idea of what is and isn't acceptable as a
message (yes, there is a very large common ground).
Why not focus on Verifiable/Validated senders and let other systems worry
about the policy for specific senders. It strikes me that it would be easy
to have a system that adds a single new header "ValidatedSender:
user(_at_)isp(_dot_)com; ...stuff including signature..." Then other systems
could
make a policy decision based on that _verifiable_ header.
This header could/would be inserted at the ISP level, rather than the MUA
level, provided they believed in the senders authenticity (via trust based
systems, SMTP AUTH, etc.).
David
--koblas
----- Original Message -----
From: "Ken Hirsch" <kenhirsch(_at_)myself(_dot_)com>
To: <asrg(_at_)ietf(_dot_)org>
Sent: Thursday, May 01, 2003 2:49 AM
Subject: Re: [Asrg] Proposal for transition to authenticated email
Gah! I forgot one other important advantage of my proposal. End users can
get
certificates and use them with current MUA software. That way they won't
be subject
to challenge-response even if they have to send through a
non-participating SMTP
server. The free certificates that just certify your email address would
not be
acceptable, but the certificates don't have to be out of reach of
individuals.
There has to be some real effort to check real-world identity, plus, as I
said in
another message:
A certificate that provides strong identity (e.g. government-issued) is
not by itself sufficient as an antispam certificate. A CA would have
to (1) check it against a database of known spammers (2) get the person
to sign a contract to abide by a set of antispam policies and (3) have
a set of procedures to handle complaints against the person (including
reporting the person to the database if they do not cooperate).
From: "Ken Simpson" <ksimpson(_at_)ttul(_dot_)org>
Instead of certificates, why not just use the Bonded Sender approach
and
use PTR queries to a whitelist DNS server or group of servers? A quick
DNS
query is less intensive than cryptography and requires less
programming.
Besides, running a CA is a huge undertaking.
This is a possibility. A DNS query may be less computationally
intensive,
but I think it takes more time. A DNS query would avoid the byte
overhead
of a message signature.
The advantage of cryptographic signatures is they prove that the message
was
sent by the holder of the private key. This helps prevent malicious
complaints against a bonded sender.
There are already CAs. I think that they would work with an
organization
such as TRUSTe rather than try to handle complaints themselves. They
could
work with more than one organization. The exact details about
certificate
signing and revocation would need to be worked out.
Other differences of my proposal from the Bonded Sender approach--
More than one policy could be chosen. Getting consensus on just one
is
hard.
Participating servers should require a challenge-response on all mail
from
non-participating servers.
Labeling properties of individual messages and senders is encouraged.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg