summaryrefslogtreecommitdiff
path: root/mail/docs/mail_journey.rst
diff options
context:
space:
mode:
authorKali Kaneko (leap communications) <kali@leap.se>2016-08-29 23:05:33 -0400
committerKali Kaneko (leap communications) <kali@leap.se>2016-08-29 23:05:33 -0400
commit43df4205af42fce5d097f70bb0345b69e9d16f1c (patch)
tree3850a0ed0748476b37e2850bbdc10d10aadfbbbd /mail/docs/mail_journey.rst
parentaa882b7a64f2c821c8e241a5ff725f27c64fc15f (diff)
parent8e4746835a1a053558ff06d4fd12b31167a80296 (diff)
Merge leap_mail into unified bitmask repo
Diffstat (limited to 'mail/docs/mail_journey.rst')
-rw-r--r--mail/docs/mail_journey.rst40
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