diff options
| author | Kali Kaneko (leap communications) <kali@leap.se> | 2016-10-03 20:40:03 -0400 |
|---|---|---|
| committer | Kali Kaneko (leap communications) <kali@leap.se> | 2016-10-03 21:48:27 -0400 |
| commit | 5519d02f609a87b0ca47a8e82c116811005b6277 (patch) | |
| tree | eea053d2ff8f99a80b2595119cfae829781135a1 /docs/mail-journey.rst | |
| parent | 8cdbf714b905246363221089bbf8579e7c8e020c (diff) | |
[docs] revamp bitmask dev docs
Diffstat (limited to 'docs/mail-journey.rst')
| -rw-r--r-- | docs/mail-journey.rst | 40 |
1 files changed, 0 insertions, 40 deletions
diff --git a/docs/mail-journey.rst b/docs/mail-journey.rst deleted file mode 100644 index 7e64f186..00000000 --- a/docs/mail-journey.rst +++ /dev/null @@ -1,40 +0,0 @@ -.. _mail_journey: - -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 --------------------------------------------------- - -1. the mx server receives an email, it gets through all the postfix validation and it's written into disk -2. ``leap_mx`` gets that write in disk notification and encrypts the incoming mail to its intended recipient's pubkey -3. that encrypted blob gets written into couchdb in a way soledad will catch it in the next sync - - -Client-side: fetching and processing incoming email ---------------------------------------------------- -you have an imap and an smtp local server. For IMAP: - -1. soledad syncs -2. **fetch** module sees if there's new encrypted mail for the current user from leap_mx -3. 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 -4. desktop client is notified that there are N new mails -5. when a MUA connects to the **imap** local server, the different documents are glued - together and presented as response to the different imap commands. - - -Client side: sending email --------------------------- - -1. you write an email to a recipient and hit send -2. the **smtp** local server gets that mail, it checks from whom it is and to whom it is for -3. it signs the mail with the ``From:``'s privkey -4. it retrieves ``To:``'s pubkey with the keymanager and if it finds it encrypts the mail to him/her -5. if it didn't find it and you don't have your client configured to "always encrypt", it goes out with just the signature -6. else, it fails out complaining about this conflict -7. that mail gets relayed to the provider's **smtp** server |