1   29 March, 2020
 2
 3Introducing mael
 4
 5An experimental mail client
 6
 7   Update: The code lives here: [1]https://github.com/icyphox/mael
 8
 9   I've been on the lookout for a good terminal-based email client since
10   forever, and I've tried almost all of them. The one I use right now
11   sucks a little less -- [2]aerc. I have some gripes with it though, like
12   the problem with outgoing emails not getting copied to the Sent folder,
13   and instead erroring out with a cryptic EOF -- that's literally all it
14   says. I've tried mutt, but I find it a little excessive. It feels like
15   the weechat of email -- to many features that you'll probably never
16   use.
17
18   I need something clean and simple, less bloated (for the lack of a
19   better term). This is what motivated me to try writing my own. The
20   result of this (and not to mention, being holed up at home with nothing
21   better to do), is mael.^[3]1
22
23   mael isn't like your usual TUI clients. I envision this to turn out
24   similar to mailx -- a prompt-based UI. The reason behind this UX
25   decision is simple: it's easier for me to write. :)
26
27   Speaking of writing it, it's being written in a mix of Python and bash.
28   Why? Because Python's email and mailbox modules are fantastic, and I
29   don't think I want to parse Maildirs in bash. "But why not pure
30   Python?" Well, I'm going to be shelling out a lot (more on this in a
31   bit), and writing interactive UIs in bash is a lot more intuitive,
32   thanks to some of the nifty features that later versions of bash have
33   -- read, mapfile etc.
34
35   The reason I'm shelling out is because two key components to this
36   client, that I haven't yet talked about -- mbsync and msmtp are in use,
37   for IMAP and SMTP respectively. And mbsync uses the Maildir format,
38   which is why I'm relying on Python's mailbox package. Why is this in
39   the standard library anyway?!
40
41   The architecture of the client is pretty interesting (and possibly very
42   stupid), but here's what happens:
43     * UI and prompt stuff in bash
44     * emails are read using less
45     * email templates (RFC 2822) are parsed and generated in Python
46     * this is sent to bash in STDOUT, like
47
48msg="$(./mael-parser "$maildir_message_path")"
49
50   These kind of one-way (bash -> Python) calls are what drive the entire
51   process. I'm not sure what to think of it. Perhaps I might just give up
52   and write the entire thing in Python. Or...I might just scrap this
53   entirely and just shut up and use aerc. I don't know yet. The code does
54   seem to be growing in size rapidly. It's about ~350 LOC in two days of
55   writing (Python + bash). New problems arise every now and then and it's
56   pretty hard to keep track of all of this. It'll be cool when it's all
57   done though (I think).
58
59   If only things just worked.
60     __________________________________________________________________
61
62    1. I have yet to open source it; this post will be updated with a link
63       to it when I do.
64
65References
66
67   1. https://github.com/icyphox/mael
68   2. https://git.sr.ht/~sircmpwn/aerc
69   3. https://icyphox.sh/home/icy/leet/site/build/blog/mael/temp.html#fn:oss