From: "Vernon Schryver" <vjs(_at_)calcite(_dot_)rhyolite(_dot_)com>
[...]
On the other hand, an x.509 cert tells you less than the typical domain
name whois data even with the best of intentions by all parties. The
name and address in domain name whois data is often maliciously bogus
for spammers. Why wouldn't the same apply to certs?
Mainly because the certs will cost a lot more than an IP address. The
contents of these certificates need to be standardized.
Note CAs and certificate issuers are quite different (assuming as you
must that there are no self-signed certs). In your model CAs are very
much like ARIN.
Wrong. In my proposal, the CAs are _required_ to have a procedure to
handle spam complaints and have automatic revocation checking of
certificates. ARIN, APNIC, etc. only allocate addresses and refuse to get
involved in spam prevention.
Can you tell the spam policy of responsible party?
Now: no (never in machine-usable form; hard to find for humans)
Proposal: yes, it's right there in certificate, in standard form
So your certs include some sort of spam policy? I missed that. Why
would it work better than the abject failure that is the "web page
privacy policy" protocol?
Because these policies would be used by programs at all the major ISPs. The
P3P doesn't really have any automated use.
Why would it be an honest statement? What
outfit would have certs that say "we send spam"?
Probably quite a few would say "we send spam". More to the point, there is
no universally accepted definition of spam, but this proposal allows senders
to declare exactly what email they allow as well as, optionally, the
properties of the individual messages and senders.
Of course it is not going to be 100% accurate and honest. That is why there
are mandatory procedures for resolving complaints.
Why wouldn't it be
the same as the current anti-spam policies of ISPs? Today you can
instantly find the ISP that issued an IP address "cert" and review
its spam policy.
1) It is _not_ easy even for a human to find the policy.
2) It is impossible to programs to use this information.
3) There is no standard way to tell if they are in compliance.
Can you show that spam was sent from server?
Now: no
Proposal: yes, cryptographically signed
That is simply wrong. All spam carries the unforgeable signature
of a sending IP address.
Unforgeable? Well I guess you sent this spam, then!
Received: (from vjs(_at_)localhost)
by calcite.rhyolite.com (8.12.9/8.12.9) id h3TGUhsH011243
for asrg(_at_)ietf(_dot_)org env-from <vjs>;
Tue, 29 Apr 2003 10:30:43 -0600 (MDT)
From: Vernon Schryver <vjs(_at_)calcite(_dot_)rhyolite(_dot_)com>
Message-Id:
<200304291630(_dot_)h3TGUhsH011243(_at_)calcite(_dot_)rhyolite(_dot_)com>
Subject: + Database of 200 mil U.S. Citizens! vtb m
[rest deleted so I don't trigger content filters]
Gee, I swear I got this! S/MIME solves this problem, although SMTP-over-TLS
doesn't (unless you keep an impractically large log.)
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg