summaryrefslogtreecommitdiffstats
path: root/2022/talks/mail.md
blob: 57e74f05dfc2a5731ce6d3ad488f9d0dc7cf7961 (plain) (blame)
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
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
[[!meta title="Revisiting the anatomy of Emacs mail user agents"]]
[[!meta copyright="Copyright © 2022 Mohsen BANAN"]]
[[!inline pages="internal(2022/info/mail-nav)" raw="yes"]]

<!-- Initially generated with emacsconf-generate-talk-page and then left alone for manual editing -->
<!-- You can manually edit this file to update the abstract, add links, etc. --->


# Revisiting the anatomy of Emacs mail user agents
Mohsen BANAN (MO-HH-SS-EN, he/him, <mailto:emacs@mohsen.1.banan.byname.net>)

[[!inline pages="internal(2022/info/mail-before)" raw="yes"]]

Actually, it makes very good sense to use Emacs as your Mail User Agent (MUA). A dominant and fundamental aspect of
mail composition and mail processing is editing. And, if you live inside of Emacs, of course you expect to have the
ultimate messaging environment.

Over the years many Emacs MUAs have appeared. As of 2022, the following Emacs MUAs are available to choose from:
Rmail, Gnus, VM, WanderLust, Mew, mu4e and notmuch.el.

Emacs MUAs can be used as Monolithic-MUAs (with elisp smtp and imap protocol implementations) or as Split-MUAs (with external
smtp and imap protocol implementations). We make a case for superiority of the Split-MUA model.
Recent evolutions of Gmail and Outlook towards requiring OAuth and our agility to better address that
requirement based on the Split-MUA anatomy is one of our justifications for converging
towards the Split-MUA anatomy.

While what we are presenting here applies to all Emacs MUAs, our focus is Gnus.
Gnus is distributed with Emacs proper and is the richest and most potent MUA, anywhere!

We have wrapped all that is needed to use Gnus as a complete Split-MUA for Unix-like environments in a package
called MARMEE (Multi-Account Resident Message Exchange Environment).

MARMEE consists of a set of packages that span:

Deb GNU/Linux Packages
MyPi Python Packages
Emacs Elisp Packages
plus everything that is needed to properly install these on Debian-like GNU/Linux systems and
integrate them with Gnus. By choice, we have limited our integration languages to elisp, python and bash.

MARMEE component packages include:

EoQmail (deb+MyPi) – Edge oriented Qmail, as a Resident Mail Submission UA.
qmail-remote is replaced by a python implementation which includes OAuth awareness.
qmail-inject is replaced by a python implementation which is X822-Bus aware (for DSN requests)
offlineimap (MyPi) – as a Resident Mail Retrieval UA.
offlineimap includes OAuth awareness.
notmuch (deb) – for searching
gpg (deb) – for privacy and integrity
flufl.bounce (MyPi) – for bounces and DSN (Delivery Status Notification) processing.
bisos.cs (MyPi) – BISOS CommandServices for configuration and secrets management and integration.
gmailOauth2.cs (MyPi) – For SMTP and IMAP authentication/authorization through gmail.com
Used by qmail-remote for out-going and by offlineimap for in-coming OAuth based mail.
org-msg (EmacsPkg) – For HTML-composition in org-mode and for htmlized citations.
mcdt (EmacsPkg) – Mail Composition, Templating, Distribution and Tracking.
The integration framework for MARMEE is BISOS (ByStar Internet Services OS).
Full integration of Emacs, MARMEE and BISOS is called Blee (ByStar Libre-Halaal Emacs Environment).
The easiest way to use MARMEE is to install BISOS – which includes Blee.

In this talk I will demonstrate what a wonderful environment the Split-MUA model of Gnus+MARMEE can be.

After walking through the concepts and the integration framework, I'll walk through transparent access to
multiple mail servers conveniently and show org-mode composition of BIDI emails going out as html.

My primary goal is to show that these packages can be integrated, but that integration is not simple.
furthermore, various improvements can be made to the packages to improve the complete integrated environment.
I'll be enumerating my requests from relevant package managers.
If we were to collectively buy into something like this, we can greatly simplify use of Emacs MUAs
with all mail systems – including the commonly used gmail and outlook.

Of course, we should not be using gmail and outlook. Instead we should extend Libre Software into Libre Services
and provide for edge-oriented autonomy and privacy in the services domain. There is a services side to
what we have presented here. It is called "The Libre-Halaal By\* (ByStar) Digital Ecosystem" – <http://www.by-star.net/>
Perhaps that could be a topic for the next EmacsConf.



[[!inline pages="internal(2022/info/mail-after)" raw="yes"]]

[[!inline pages="internal(2022/info/mail-nav)" raw="yes"]]

[[!taglink CategoryMail]]