keyserver for recipient key discovery

[david415]

i just now noticed mailproxy doesn't use the keyserver. looks like there's even a QueryKeyFromProvider but it remains unused.

if @Yawning doesn't have time i can make sure mailproxy falls back to using the keyserver for retrieving recipient keys... i'd also want to make the SMTP proxy accept messages instead of rejecting them if the RCPT TO command specifies a recipient not already in the mailproxy config.

[Yawning]

It was a deliberate design decision not to make it fall back, and to reject unknown recipients.

The key server (and all responses) are untrusted. If someone wishes to automate some of this process, they are able to do so with the APIs provided, however the standalone version of this software will not engage in behavior that is questionable.

[mixmasala]

I spoke with @david415 today and we thought that we should have tofu automated key lookups and a place to store recipient identities (rather than hardcoding them in a configuration file). In addition to @Yawning comment above, automagically fetching and storing keys requires handing outgoing messages that don't yet have a recipient public key differently than messages that do. I thought about this a bit and wanted to know what you both think about the following proposals:

Proposal: respond with a message stating that the recipient is unknown, and that a keyserver lookup can be performed by replying to that message. Upon lookup of a recipient, another message is placed in the user's mail spool indicating the status of the lookup. If the lookup is successful, the message displays the retrieved public key, which the user must reply to again in order to save the identity. If the lookup is unsuccessful, a message stating so is used instead with no further action possible.

Proposal: respond with a message stating that the recipient is unknown and a keyserver lookup has been performed on behalf of the user. When the keyserver lookup has returned, another message is used to display the key retrieved, to encourage the user to verify the key out-of-band, and display actions the user may take by replying with an action (keep, reject, retry).

Proposal: As above, but the default action is to store the key and allow the user to reject the retrieved key.

Proposal: Don't change the default behavior for RCPT TO, but allow the user to request a keyserver lookup by sending a mail to a well-known identity (something like keys@katzenpost), and providing some similar email-based interface as one of the options above.

Proposal: Write a small client that uses the mailproxy api to lookup identities and interactively update a recipient boltdb store. Note that in all the above proposals, recipient identities would be placed in a boltdb store rather than rewriting mailproxy's configuration .toml

Yes, this sounds a bit kludgy, but would work with various mail clients and sounds fairly straightforward to implement. Thoughts?

[david415]

@mixmasala from my perspective we should make the quickest easiest changes now in order to get a useable application to showcase in order to "answer questions about our mixnet" rather than a more sophisticated application with a comprehensive and powerful threat model.

[mixmasala]

Do any of the proposals seem preferable to the others? I'd also like @Yawning to give input because I don't want to spend time writing something that no one wants/merges.

[moba]

I suggest a configuration option to autofetch keys, disabled by default but enabled in the playground release: Mails to unknown recipients are queued, and a non-delivery message returned only if a key could not be looked up during some timeout period.

[mixmasala]

Ok - after some thought/discussion with moba I think that this is a good approach. Question: does it make sense to have a mailproxy-wide recipients database (as is the current recipient Store) or add another bucket to the existing per-account storage database?

[mixmasala]

Per discussion I've added PEM encoded recipient support to mailproxy in https://github.com/katzenpost/core/pull/46, https://github.com/katzenpost/daemons/pull/9, and https://github.com/katzenpost/mailproxy/pull/35

[mixmasala]

https://github.com/katzenpost/mailproxy/pull/36

[david415]

fixed forever