> A dishonest site will have a poor-quality feed, and may be disciplined by being ignored.
So you're really just doing current antispam, with some additional identification which may or may not be respected (its value relies in forcing manual labor on initial key exchange) and may or may not be scalable (say you put a new honest mailserver online -- are you going to statically exchange keys with all other servers out there? And how do you verify a key is still valid at any point? Are you going to pull something out of DNS? this sounds familiar...). Hardly a silver bullet IMHO, sorry.
> Completely and totally wrong, since in the model I'm talking about reputation is local to my site, not shared.
It doesn't matter: you're a stolen key away from suffering. If I get your key and start signing spam with it, sending it all over the place, you'll soon be overflowed by "yo!"s, you'll have to regenerate keys, rebuild trust (a process you've forced to be slow), and your mail won't go through for days or weeks. The typical exactness of caching algorithms will ensure that minor servers will still be "yo!"ing you for months or years, and again your mail won't go through.
We really have no idea how many private keys get stolen every day. They are just not deployed unless they produce valuable activity (accessing a control panel, signing a malicious driver and so on). Spamming is an immediately-valuable activity, so they would become prized loot overnight.
Also, we've seen enough attacks on HTTPS and other "secure" implementations by now, that we should know signatures are not a panacea.
And all this effort just to add "another signal" to the pile of checks we already do...
> Better than whitelists, no?
They are effectively the same thing, which is why the following option in the list is "Whitelists suck".
> (X) Countermeasures must work if phased in gradually
Why?
Are you going to have "email switch day"? Good luck with that. Look at IPv4 vs IPv6, email is on that scale.
EDIT: apologies, I see you were concentrating on NNTP. However, I don't think the two worlds are particularly dissimilar -- NNTP just never reached the scale and criticality of SMTP, at which point your solution becomes basically unmanageable.
> its value relies in forcing manual labor on initial key exchange
Setting up NNTP peers has always been manual, and one has always gotten one's newsfeed through one's peers which is why this can work; as your edit noted, this can't work for SMTP because it's a different model.
> If I get your key and start signing spam with it, sending it all over the place, you'll soon be overflowed by "yo!"s, you'll have to regenerate keys, rebuild trust (a process you've forced to be slow), and your mail won't go through for days or weeks.
And for NNTP that would be okay.
Solving the SMTP spam problem is something else entirely, and I wouldn't want to taken on that burden. But Usenet could have been saved.
So you're really just doing current antispam, with some additional identification which may or may not be respected (its value relies in forcing manual labor on initial key exchange) and may or may not be scalable (say you put a new honest mailserver online -- are you going to statically exchange keys with all other servers out there? And how do you verify a key is still valid at any point? Are you going to pull something out of DNS? this sounds familiar...). Hardly a silver bullet IMHO, sorry.
> Completely and totally wrong, since in the model I'm talking about reputation is local to my site, not shared.
It doesn't matter: you're a stolen key away from suffering. If I get your key and start signing spam with it, sending it all over the place, you'll soon be overflowed by "yo!"s, you'll have to regenerate keys, rebuild trust (a process you've forced to be slow), and your mail won't go through for days or weeks. The typical exactness of caching algorithms will ensure that minor servers will still be "yo!"ing you for months or years, and again your mail won't go through.
We really have no idea how many private keys get stolen every day. They are just not deployed unless they produce valuable activity (accessing a control panel, signing a malicious driver and so on). Spamming is an immediately-valuable activity, so they would become prized loot overnight. Also, we've seen enough attacks on HTTPS and other "secure" implementations by now, that we should know signatures are not a panacea.
And all this effort just to add "another signal" to the pile of checks we already do...
> Better than whitelists, no?
They are effectively the same thing, which is why the following option in the list is "Whitelists suck".
> (X) Countermeasures must work if phased in gradually
Why?
Are you going to have "email switch day"? Good luck with that. Look at IPv4 vs IPv6, email is on that scale.
EDIT: apologies, I see you were concentrating on NNTP. However, I don't think the two worlds are particularly dissimilar -- NNTP just never reached the scale and criticality of SMTP, at which point your solution becomes basically unmanageable.