require MUA upgrades. Consider this message, signed with PGP using
Windows Privacy Tools, all open-source despite that I'm using Outlook
2000.
... with SenderKeys, the ISP or personal domain user,
simply responds to a enticement e-mail
Enticement email = spam, sorry.
I get a different read on this algorithm; perhaps if I re-summarize it:
SenderKeys is like PGP in that messages are signed using public-key
encryption.
Correct.
Additionally, if a message is not signed, the receiver can generate a free
private key using his authority server for the sender address and mail it
back to the user in the "enticement" email. Its not mentioned, but
presumably if he doesn't trust your authority server he could ignore the
signature and send you an additional key (the SenderKeys docs mention that
multiple signatures may be included with the message).
Correct.
If your MUA has already been upgraded, it should intercept this message
and start using that private key to send emails automatically. Otherwise,
there will be a link in there telling you how to upgrade your MUA.
Correct.
Thus the problem is completely localized to the MUA, satisfying his
apparent goal - to avoid changes on the server.
Correct. Kudos on being so astute. Thanks!
I imagine there would be a market among advanced computer users (someone
who would install Windows Privacy Tools, maybe) who are using the email
address and mail servers provided their ISP (e.g. joe(_at_)aol(_dot_)com) and
are
therefore unable to implement filtering etc. on the server-side.
The authority can also be a server-side filter, as AccuSpam is.
So the market is not limited as you state.
The implementation would have to be careful, however, not to repetitively
send enticement mails to people who don't install SenderKeys, because
SenderKeys will not be accessible to everyone.
This could be a simple link in the enticement to click "Do not entice me to use
SenderKeys".
We do not need a Catcha hassle because the spammer won't get the enticement if
he is forging a sender.
The SenderKeys overview mentions that you could configure it to only send
the enticement if the user is blacklisted (as opposed to
non-whitelisted). I suppose this means that if you start receiving spam
from a particular address you blacklist it manually; if it is a real user
they will be forced to install SenderKeys in order to communicate (or is
there a challenge-response backup?).
AccuSpam has a challenge-response backup for blacklisted addresses, as well it
ages (removes from blacklist) so individual addresses are not the target of the
blacklist. An occassional forging of your address will leave no lasting
footprints. Only a sustained forging of your address could cause you to have
to do a challenge-response, but then you've got bigger problems any way if SPF
is not already protecting you. You see I think people here failed to realize
that SPF can be a first line of defense so you only do SenderKeys if you really
need it (SPF not stopping forgery and you getting a hell of lot of forgery).
It is a market driven then. We do not decide. The users do.
In the blacklist case, the
'enticement emails' would be delivered as bounces I suppose.
What difference are you referring to between a bounce and an auto-response?
Then I can answer. I think the challenge-response for blacklist case (remember
AccuSpam does not challenge-response in non-blacklist case) is just another
auto-response. What are you getting at?
My suspicion is that this would become the most common use. I used to use
tmda and I have disabled its challenge-response mechanism because it is
too confusing for novice users and blocks receipts, mailing list
confirmations, and order confirmations from online services.
100% AGREED!!! I hate CR anti-spam! AccuSpam is not CR anti-spam. It is CNR
anti-spam. See below for more on that.
No the CR are only sent in the blacklist case, and again these CR will also be
saying that you can either do the CR or enable your MUA for SenderKeys for a
lasting solution. Or click a link which says "Do not send me these
auto-responses".
In any case, this is not the major case, because how many times has your
address been forged recently? Be realistic. If you are being heavily forged,
then you either need to do "-all" for SPF or SenderKeys. AccuSpam does not
care. Either one will solve it and stop the blacklisting. AccuSpam supports
and uses SPF (sorry I forgot to mention that).
So if you do nothing and you are getting heavily forged, then you are going to
blacklisted in Spam Assassin and other anti-spam also. It is not peculiar to
SenderKeys (or AccuSpam).
Forgery and errant blacklisting is one of the problem we are trying to solve
with SPF and SenderKeys.
In this
mode, however, SenderKeys is not an anti-spam solution for the receiver,
it just prevents impersonation when sending mail to other SenderKeys users
and allows SenderKeys users to bypass the blacklists of other SenderKeys
users. Spammers can continue to bypass the system the same way they've
been bypassing blacklists all along.
Incorrect.
SenderKeys stops the receiver from receiving the forgery. Same as for SPF if
"-all".
The performance of blacklisting is not the point of SenderKeys or SPF. Each
kind of blacklisting is different. AccuSpam uses domain reputation
blacklisting which is very effective (91% already).
Compared to tmda:
It appears you are comparing AccuSpam to a CR system and AccuSpam is not a CR
system.
Besides, SenderKeys is not anti-spam, just as SPF is not anti-spam, they are
both anti-forgery.
If you want to discuss the anti-spam side of things, just make sure we are not
discussing SenderKeys then, just as if we were discussing how Spam Assassin
deletes spam, we are not discussing SPF, even though SPF integrates with Spam
Assassin.
- tmda only requires intallation on the receivers' side
Tmda is for anti-spam. Same as AccuSpam for anti-spam.
- tmda does not require senders to upgrade their MUA
Neither does AccuSpam. But if TMDA wants to delete forgery with it needs
either SPF "-all" or SenderKeys, just like AccuSpam and SpamAssassin do.
Note that without "-all", AccuSpam, TDMA, and Spam Assassin (and any other
anti-spam) can assign perhaps a 90% probability of forgery but not 100%.
- SenderKeys allows an address to be whitelisted only if its messages are
cryptographically signed
SenderKeys has nothing to do with the decision of what gets whitelisted. Each
anti-spam does whitelisting in a different way. AccuSpam's method is very
different than what you are describing. AccuSpam lets the recipient decide
what to whitelist. AccuSpam is able to delete (currently 91% and rising) of
the spam before it asks the recipient whether to whitelist.
- whereas in tmda you can tell them to use a sender-specific address to
email you
I have already discussed the disadvantages of disposeable email addresses
(irrelevant any way to SenderKeys only relevant to anti-spam discussion):
http://www.windowsbbs.com/showpost.php?p=179171&postcount=21
Note: If you are willing to upgrade the senders' MUA, then of course you
could automate the process of acquiring a tmda sender-specific email
recipient address; this would be functionally equivalent to SenderKeys
except the message body would not be protected from tampering.
It would be Tmda and disposeable address specific and would not interopt with
all possible verifiers who want to do anti-forgery. Additionally, SenderKeys
gives much flexibility to verifiers as to what to trust and how to combine the
results from different authorities. There is much room for people to add their
own algorithms and value to the anti-forgery which might exceed what we could
imagine.
I don't aticipate that spammers will tamper - oh the horror! I can just
see a letter from my mother suffixed with a bunch of random words and a
link to some maternal rape site.
LOL! :)
Compared to SPF:
- with SPF, *(_at_)domain are taken care of, SenderKeys does individual sender
addresses
If ALL users of *(_at_)domain can be verified to be ALWAYS doing SMTP AUTH on
the approved mail servers, which I assert is impossible for an large ISP to
EVER verify.
- with SPF, central administration is dealt with using DNS; SenderKeys
include an authority URL with each key, and any user may have a keypair on
any authority
Correct except that expect the market to give precedence to authorities of
known stature and policies to be developed.
Multiple authorities might be more redundant than DNS, but I have no quibbles
with SPF here. DNS is okay. Just can't use DNS for sender granularity so had
to invent something else.
- SenderKeys can be installed without adminstrating a server (except the
authority server, perhaps)
Yes but much less authorities needed as compared with SPF DNS records.
- SenderKeys uses cryptographic signatures to identify the sender, SPF
uses the IP address of the delivering server
Correct. Very important point because for example this is why SPF breaks
forwarding and SenderKeys does not.
- SPF spreads by accompanying the old mantra "close open relays!" with a
new mantra "close open domains!", SenderKeys spreads from person to person
as the enticement bounces are read by non-users (these messages are
automatically handled and removed by the SenderKeys software).
Or SenderKeys spreads by simply users upgrading their MUAs after seeing a new
feature listed for the upgrade:
"Stops most forgery of your email addresses automatically".
You are pretty much dead on correct in most of your post, except you have big
misunderstanding on this following final point:
I would give SenderKeys an overall thumbs down. MUA-based solutions don't
gain traction.
That we can debate. POP gained traction. Without MUA traction (get all users
to upgrade to latest version of their MUA and manually configure), how will you
ever get SMTP AUTH? Without SMTP AUTH, how will you get "-all" for SPF
domains? Without "-all", how can you detect forgery with 100% certainty with
SPF?
Blacklist-based systems don't stop SPAM.
Here you are evaluating SenderKeys in terms of the authority's algorithm for
when to auto-respond. What you assume is that for example, AccuSpam is
blacklisting individual addressses, which is not the case. AccuSpam is
counting the disapproval vs. approval ratio for a domain:
"STATISTICAL BLOCKING BY DOMAIN"
http://forums.speedguide.net/showpost.php?p=1384560&postcount=114
then if it is a spammer domain (one that sends > 99% spam from a probablistic
metric ... not pure ratio), then it blacklists the entire spammer domain (e.g.
gooddeals.com, a001.com, etc). The statistics theory prevents blacklisting of
domains that send some non-spam.
So the blacklisting of AccuSpam does stop spam. In fact, 91% as of last
measurement on average for all our users! It will exceed 99% once we reach
10,000+ users.
In essense, AccuSpam is (domain reputation) what people are hoping SPF will
enable for anti-spam. And I am telling you that SPF will not really help until
we can say "-all" for all major ISPs and then ultimately for all personal
domains, as spammers move their forgery to domains that are not "-all".
And I am saying it is going to very, very difficult to get "-all" for all
domains. Much better to have a sender granularity, since it is the sender that
is most harmed by forgery of his address. Realize that an ISP can not "-all"
until **ALL** (every single one) customer has been confirmed to be using
exclusively the mailservers of the ISP.
How is the ISP going to confirm that?
Impossible. There simply isn't any mechamisn in SPF to confirm that or to
remind the user. And what you going to do for users who upgrade their MUA (to
SMTP AUTH) but can't figure out how to use it correctly? At least with
SenderKeys they upgrade their MUA and it happens automatically.
There are so many reasons, I could go on and on and on...
And
whitelist-based systems block the most important mail - "Your order has
been shipped" and "Please confirm your email address".
I already said that AccuSpam does not do this. AccuSpam is radical new
invention called "CNR" - Challenge Non Response.
AccuSpam sends a confirmation (not challenge) auto-response to new senders (not
yet on white or blacklist). The sender is not required to do anything. Then
AccuSpam deletes (currently 91% and rising) of the spam by STATISTICAL BLOCKING
BY DOMAIN as detailed above. Then remaining email is shown to the user has a
Daily Summary email which user can request any non-spam to be delivered to
Inbox.
So it is impossible for AccuSpam to block legitimate email unless your domain
is sending 99+% spam.
Thanks,
Shelby