summaryrefslogtreecommitdiff
path: root/docs/mail-journey.rst
blob: 7e64f186f1cbcadea931133bac5f9fabf2fc08e2 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
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