One alternative to SMTP for email: Confidant Mail

MFPA 2014-667rhzu3dc-lists-groups at
Sat Mar 28 15:59:22 CET 2015

Hash: SHA512


On Thursday 26 March 2015 at 11:57:43 PM, in
<mid:55149CF7.2070400 at>, Mike Ingle wrote:

> That's more or less what it does. When you get an email
> from  joe at, it fetches that key id and
> adds it to your keyring. If you get an email from a
> different key claiming joe at, it also
> fetches that key id and adds it, but now messages from
> both users show a key collision until you go delete one
> of those keys.

Why should the user need to delete one, rather than just be told there
were two and the one with such-and-such a fingerprint (or the one
highlighted) signed this message? If it is just a string in a key UID
rather than a functional email address, it will not necessarily be

> Likewise,  while you have a key
> collision, you cannot email that user by typing his
> email address. You have to type or click the key id. In
> that way it  forces you to deal with it when and if you
> get a collision.

I guess a future UI enhancement might be the ability to specify a key
id in a contact list entry. Or something akin to Enigmail's
Per-recipient rules.

> Think I should rephrase that like, "SMTP-style
> addresses can be used to look up keys"?

I think it is a good idea to re-phrase it so that you are not stating
the user can keep their existing SMTP email address, and also to make
it clear this identifier is used only for key look-up and not for
message delivery.

> It is true that
> people can always keep and use their existing address,
> but others can potentially generate fake keys for that
> address.

It is also true that some email providers recycle email addresses that
have fallen out of use. Out of seven yahoo addresses I used for
consecutive periods between 2004 and 2009, six are currently available
to be registered. (The odd-one-out is from 2006.) I have left each one
active with an auto-forward to the next.

> The celebrity will not be blocked because there is no
> central key  directory. It's possible some impostor
> will start using a celebrity's  email address on CM.
> Then when the real celebrity wants to use it, he  will
> tweet "My real CM key id is (some hash), please ignore
> those  impostors" and hopefully that will resolve it.

That is re-assuring to hear. See also my first comment, above.

> It's similar to regular PGP keyservers in that it will
> accept any key someone wants to post. The main
> difference is keys expire after a month or so if they
> are not  re-posted.

In a similar way to a file that has not been requested for a
relatively long time dropping off a peer-to-peer filesharing network?

> The only person who will see a key collision is one who
> previously  received a message from the impostor.

Or subsequently received a message from the imposter, then goes back
to look at the message that was not from the imposter, presumably.

> Yes I am worried about the bogus keys problem. Just not
> sure how to  handle it in a peer to peer system.

Is there a way to incorporate some sort of challenge/response at key
creation time before the key is uploaded to the peer-to-peer system?
Or could the challenge/response be handled by a number of
"verification agents" incorporated into the peer-to-peer network?

> Anyone can run
> a provider and I expect them to range  from strictly
> business to the dodgy darknet variety.

Using "darknet" services to enhance privacy does not equate to
"dodgy". A person's communications are none of anybody else's
business, apart from whoever they choose to communicate with.

- --
Best regards

MFPA                  <mailto:2014-667rhzu3dc-lists-groups at>

Oven mitt: A partially charred grease stain that fits over the hand.


More information about the Gnupg-users mailing list