diff options
author | Ruben Pollan <meskio@sindominio.net> | 2014-08-26 11:05:33 -0500 |
---|---|---|
committer | Ruben Pollan <meskio@sindominio.net> | 2014-08-26 11:06:08 -0500 |
commit | f900e3a5f90a3af4ae6a0522ac73f0116cf185a9 (patch) | |
tree | c3a502dcf39412671b393a06b28c038f0c9a9cb9 /mail/docs/mail_journey.rst | |
parent | dfc2cb3cc5bd5f38234253a2a0c960b6581d8e88 (diff) | |
parent | 8ad0a200050a51ff52b7db5aabeb6d65b34cf3ee (diff) |
Merge branch 'feature/sphinx-boilerplate' into develop
Diffstat (limited to 'mail/docs/mail_journey.rst')
-rw-r--r-- | mail/docs/mail_journey.rst | 40 |
1 files changed, 40 insertions, 0 deletions
diff --git a/mail/docs/mail_journey.rst b/mail/docs/mail_journey.rst new file mode 100644 index 0000000..7e64f18 --- /dev/null +++ b/mail/docs/mail_journey.rst @@ -0,0 +1,40 @@ +.. _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 |