One alternative to SMTP for email: Confidant Mail

Mike Ingle mike at
Sun Mar 29 23:28:13 CEST 2015

 > Any word on whether confidant mail will support the openpgp smart 
cards (or
 > yubikey, similar)?  -Nick

With GPG 2.1, the gpg-agent handles all the passphrase prompting. I 
don't see
why it would not work with a smartcard. Which one do you think I should 
get to
test with? I have not played with them.

 > > 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 
 > than a functional email address, it will not necessarily be unique.

There should not be two or more keys advertised for one email address. That
creates confusion, requires the recipient to have two CM accounts, and
increases the risk of bogus keys being used. Since CM keys disappear 
from the
key search results about a month after the key owner stops advertising them,
people should delete old or bogus keys from their keyrings.

 > > 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?

Once the owner stops advertising the key (by using it in a CM account), 
a month or so the STORUTIL will remove it from the servers. That depends on
how often server operators run STORUTIL to prune their server directories.

 > 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?

Not at the moment. There is no place to put a gatekeeper in this system. 
It is
a Kademlia peer to peer network with signature and integrity checking done
before the key is accepted. Any gatekeeping will have to be done by the 
In general it's a server dumb/client smart system.

 > > 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.

No offense to the darknet intended. I'm in favor of more widespread Tor 
and I2P
usage, that's why I built in support for it. Using CM over hidden 
services is a good
way to avoid social graph building.

An example of a "dodgy darknet provider" would be if one of the darknet 
decided to run a couple of covert CM servers (having only Tor hidden service
addresses) to facilitate vendor to customer communication. That would solve
the problem of some users not encrypting their messages, and would allow 
to communicate even if the hidden website server is down.

Suppose a reporter on a "strictly business" CM provider wanted to interview
vendors of that darknet market. She could do so using CM without needing a
technical expert to handle the encryption, and without either party being
exposed to any risks. In the past that has been difficult.

It is also possible to run mailing lists and file servers over CM. I am
currently running a CM users' mailing list.


More information about the Gnupg-users mailing list