On 2 Sep 2006 02:39:15 -0000, John Levine <asrg(_at_)johnlevine(_dot_)com>
wrote:
>Your argument is not unique to my proposal but it is directed against
>all bounces, vacation messages, etc.
Right. You don't want to send a response unless you know a message
isn't spam, but if you already know it's not spam, there isn't much
point in sending a C/R challenge, is there?
My website states that the bounce would only be sent to email that has an
intermediate risk of being spam.
Incidentally, it occurs to me that S/MIME addresses the introduction
problem at least as well as your hack. Remember that S/MIME uses
hierarchical signed certificates just like SSL, and MUAs typically
have a list of well-known S/MIME signers just like the list of well
known SSL signers, more often than not the same list. All of the
signers make some desultory effort to ensure that that they only sign
certs that belong to the address on the cert, typically by mailing out
a token that you need to use to claim your cert.
Anyone with a signed cert has jumped through a hoop at least as
difficult as responding to a C/R challenge. If you whitelist all mail
with signed certs, and tell people to get an S/MIME cert if they want
to talk to you (they're free, after all), that solves the same
problems as your scheme, with added benefits of preventing snooping in
transit in the common case that the sender knows your cert, too. And
it's already available in Outlook, Outlook Express, Eudora,
Thunderbird, and probably lots of other MUAs I haven't looked at.
What are you waiting for?
I support any means by which MUAs can be used to authenticate email, and it
would be fantastic to see S/MIME signing. Obviously any signed email would
almost certainly bypass the need for a challenge and successfully reach the
inbox. There are two main reasons why I promote issuing bounces with
sub-addresses as described on my site:
1) Multiple senders can use the same sub-address thus reducing the frequency
with which bounces are issued. I can send an email to
support(_at_)business(_dot_)combut I may get a reply from
manager(_at_)business(_dot_)com(_dot_) Manager(_at_)business(_dot_)com is a
stranger yet the his email
will almost certainly reach my inbox unimpeded as he is using the valid
sub-address issued to Support. As my site states "Experience with other
sub-address generating systems suggests that 90-97% of all legitimate email
uses a sub-address that is not used by spammers." Spammers will acquire
only a fraction of issued sub-addresses.
My system is not identical to other sub-address based systems but the
principle is the same. A single one of my sub-address can be forwarded to
multiple strangers who can use it to email me. It is highly unlikely that
emails from these strangers will generate a bounce.
2) Correspondents with MUAs that lack Auto-Reply can manually resend the
bounce, thus authenticating their email. There is no zero-day when every
single MUA in the world must be updated for this system to work. This
system can authenticate every email from day one. The level of
participation for MUAs only effects the transparency of this system.
So S/MIME is good, but I'm not sure that it can substitute the above. I'm
also not sure how the mechanism of "tell people to get an S/MIME cert if
they want to talk to you" would work.
C/R systems are extraordinarily effective at eliminating spam yet they are
equally annoying. I've tried to preserve as much of efficacy of C/R as
possible and yet with a combination of Bayesian filters, sub-addresses, and
Auto-Reply I've tried to produce a system that will challenge so
infrequently that its deployment is justified. A respectable Bayesian
filter might have a 0.5% false positive rate. Under this system 0.5% of
correspondents might see a bounce/challenge while almost completely
eliminating spam. If this were to happen then the annoyance of this "C/R"
system would certainly be less than the status quo.
Thank you for your input,
Michael
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg