Exposing email addresses on key servers

[John Clizbe]

Daniel Kahn Gillmor wrote:
> On 06/29/2009 07:27 PM, reynt0 wrote:
>> I guess WK's comment is about complete strangers sending you
>> email?
> 
> I think that wasn't his point.  I think Werner's point was that when
> people send encrypted mail, they use a mail user agent (e.g. thunderbird
> with enigmail, outlook with the gpg plugin, claws, mutt, etc).  the MUA
> is usually responsible for selecting which key to encrypt the message
> to.  It does so by asking GPG to find a key which matches the e-mail
> address.
> 
> If you choose a user ID which does not exactly match your e-mail
> address, gpg (and thus the MUA) has no way of selecting the right key to
> encrypt to automatically.
> 
> Some user agents include special features for mapping e-mail addresses
> to keys manually (e.g. Enigmail in Thunderbird allows this), but it's
> yet another step in an already cumbersome process.

Enigmail actually has two ways this mapping may be done:

1) in advance, via per-recipient rules

2) ad hoc, via selecting keys in the key manager when sending.
   This is also the more cumbersome of the two

> Werner's point (I think) was that by raising the bar still further,
> you're simply discouraging people from encrypting mails to you in the
> first place, and not protecting yourself that much from harvesters, who
> have many other ways to get your address (from posts to this public
> mailing list, for example).

IAWTC. Crypto with email is difficult enough. Making it more so isn't
helpful to the adoption process.

I think the relative risk of keyserver SPAM is badly overestimated. Yes
it happens, but I don't believe it's anywhere near the degree people who
keep bring up this UID mangling "solution" must think it is.

Several years ago, the Enigmail team were discussing the very topic and
we wanted to quantify just how bad a problem keyserver SPAM was. So a
couple UIDs with heretofore unused email addresses were added to keys
and sent to the servers. At the same time, two email accounts were setup
 on GMail but left unused. After three months, the volume of SPAM to the
keyserver UID addresses was statistically indistinguishable from random
noise SPAM landing on the dormant GMail accounts. The volume itself was
quite small in comparison to what I received on a regular basis on the
ISP account used at the time for this and other technical lists; 20-30
per month versus 1000-1200 per month.

That was around 2004/2005. Folks are welcome to repeat the process to
see if the numbers have substantially changed.

> It's a bad tradeoff.

I agree. Specific spam defenses are in many ways worse than useless.
They stop an insignificant fraction of spam and add a layer of
complexity to your system.

Trying to plug up every single route by which a spammer can discover
your email address is both specific, and it has a terrible game-over.
Once it's out, it's out.  Boo hoo for you.  All that sacrifice and
inconvenience for naught.

General spam defenses are very useful; e.g., Bayesian filters in MUAs
and MTAs. A good spam filter, though -- if a spam gets through, you can
teach the spam filter to not let another one like it through.  General
defenses do not easily fall into game-over states. You can teach the
filter to avoid false negatives as well as false positives.

There are better ways of fighting SPAM than making it difficult for
others to communicate.

-- 
John P. Clizbe                      Inet:John (a) Mozilla-Enigmail.org
You can't spell fiasco without SCO. hkp://keyserver.gingerbear.net  or
     mailto:pgp-public-keys at gingerbear.net?subject=HELP

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 679 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20090629/0938bde7/attachment-0001.pgp>