The life cycle of a LEAP Email¶

The following are just some notes to facilitate the understanding of the leap.mail internals to developers and collaborators.

Server-side: receiving mail from the outside world¶

the mx server receives an email, it gets through all the postfix validation and it’s written into disk
leap_mx gets that write in disk notification and encrypts the incoming mail to its intended recipient’s pubkey
that encrypted blob gets written into couchdb in a way soledad will catch it in the next sync

you have an imap and an smtp local server. For IMAP:

soledad syncs
fetch module sees if there’s new encrypted mail for the current user from leap_mx
if there is, the mail is decrypted using the user private key, and splitted into several parts according to the internal mail data model (separating mutable and inmutable email parts). Those documents it encrypts it properly like other soledad documents and deletes the pubkey encrypted doc
desktop client is notified that there are N new mails
when a MUA connects to the imap local server, the different documents are glued together and presented as response to the different imap commands.

you write an email to a recipient and hit send
the smtp local server gets that mail, it checks from whom it is and to whom it is for
it signs the mail with the From:‘s privkey
it retrieves To:‘s pubkey with the keymanager and if it finds it encrypts the mail to him/her
if it didn’t find it and you don’t have your client configured to “always encrypt”, it goes out with just the signature
else, it fails out complaining about this conflict
that mail gets relayed to the provider’s smtp server