Introducing mael post Signed-off-by: Anirudh Oppiliappan <x@icyphox.sh>
Anirudh Oppiliappan x@icyphox.sh
Sun, 29 Mar 2020 13:00:56 +0530
3 files changed,
132 insertions(+),
1 deletions(-)
M
pages/_index.md
→
pages/_index.md
@@ -9,6 +9,7 @@ ## Computers, security & computer security.
| | | | :-- | --: | +| [Introducing mael](/blog/mael) | 2020-03-29 | | [COVID-19 disinformation](/blog/covid19-disinfo) | 2020-03-15 | | [Nullcon 2020](/blog/nullcon-2020) | 2020-03-09 | | [Setting up Prosody for XMPP](/blog/prosody) | 2020-02-18 |
M
pages/blog/feed.xml
→
pages/blog/feed.xml
@@ -11,7 +11,72 @@ <link>https://icyphox.sh/blog/</link>
</image> <language>en-us</language> <copyright>Creative Commons BY-NC-SA 4.0</copyright> - <item><title>COVID-19 disinformation</title><description><![CDATA[<p>The virus spreads around the world, along with a bunch of disinformation + <item><title>Introducing mael</title><description><![CDATA[<p>I’ve been on the lookout for a good terminal-based email client since +forever, and I’ve tried almost all of them. The one I use right now +sucks a little less—<a href="https://git.sr.ht/~sircmpwn/aerc">aerc</a>. I have +some gripes with it though, like the problem with outgoing emails not +getting copied to the Sent folder, and instead erroring out with +a cryptic <code>EOF</code>—that’s literally all it says. +I’ve tried mutt, but I find it a little excessive. It feels like the +weechat of email—to many features that you’ll probably never use.</p> + +<p>I need something clean and simple, less bloated (for the lack of +a better term). This is what motivated me to try writing my own. The +result of this (and not to mention, being holed up at home with nothing +better to do), is <strong>mael</strong>.<sup class="footnote-ref" id="fnref-oss"><a href="#fn-oss">1</a></sup></p> + +<p>mael isn’t like your usual TUI clients. I envision this to turn out +similar to mailx—a prompt-based UI. The reason behind this UX decision +is simple: it’s easier for me to write. :)</p> + +<p>Speaking of writing it, it’s being written in a mix of Python and bash. +Why? Because Python’s <code>email</code> and <code>mailbox</code> modules are fantastic, and +I don’t think I want to parse Maildirs in bash. “But why not pure +Python?” Well, I’m going to be shelling out a lot (more on this in a bit), +and writing interactive UIs in bash is a lot more intuitive, thanks to +some of the nifty features that later versions of bash have—<code>read</code>, +<code>mapfile</code> etc.</p> + +<p>The reason I’m shelling out is because two key components to this +client, that I haven’t yet talked about—<code>mbsync</code> and <code>msmtp</code> are in +use, for IMAP and SMTP respectively. And <code>mbsync</code> uses the Maildir +format, which is why I’m relying on Python’s <code>mailbox</code> package. Why is +this in the standard library anyway?!</p> + +<p>The architecture of the client is pretty interesting (and possibly very +stupid), but here’s what happens:</p> + +<ul> +<li>UI and prompt stuff in bash</li> +<li>emails are read using <code>less</code></li> +<li>email templates (RFC 2822) are parsed and generated in Python</li> +<li>this is sent to bash in STDOUT, like</li> +</ul> + +<div class="codehilite"><pre><span></span><code><span class="nv">msg</span><span class="o">=</span><span class="s2">"</span><span class="k">$(</span>./mael-parser <span class="s2">"</span><span class="nv">$maildir_message_path</span><span class="s2">"</span><span class="k">)</span><span class="s2">"</span> +</code></pre></div> + +<p>These kind of one-way (bash -> Python) calls are what drive the entire +process. I’m not sure what to think of it. Perhaps I might just give up +and write the entire thing in Python. +Or…I might just scrap this entirely and just shut up and use aerc. +I don’t know yet. The code does seem to be growing in size rapidly. It’s +about ~350 LOC in two days of writing (Python + bash). New problems +arise every now and then and it’s pretty hard to keep track of all of +this. </p> + +<p>Sigh. Why can’t stuff JustWork™?</p> + +<div class="footnotes"> +<hr /> +<ol> +<li id="fn-oss"> +<p>I have yet to open source it; this post will be updated with +a link to it when I do. <a href="#fnref-oss" class="footnoteBackLink" title="Jump back to footnote 1 in the text.">↩</a></p> +</li> +</ol> +</div> +]]></description><link>https://icyphox.sh/blog/mael</link><pubDate>Sun, 29 Mar 2020 00:00:00 +0000</pubDate><guid>https://icyphox.sh/blog/mael</guid></item><item><title>COVID-19 disinformation</title><description><. I have +some gripes with it though, like the problem with outgoing emails not +getting copied to the Sent folder, and instead erroring out with +a cryptic `EOF`---that's literally all it says. +I've tried mutt, but I find it a little excessive. It feels like the +weechat of email---to many features that you'll probably never use. + +I need something clean and simple, less bloated (for the lack of +a better term). This is what motivated me to try writing my own. The +result of this (and not to mention, being holed up at home with nothing +better to do), is **mael**.[^oss] + +[^oss]: I have yet to open source it; this post will be updated with + a link to it when I do. + +mael isn't like your usual TUI clients. I envision this to turn out +similar to mailx---a prompt-based UI. The reason behind this UX decision +is simple: it's easier for me to write. :) + +Speaking of writing it, it's being written in a mix of Python and bash. +Why? Because Python's `email` and `mailbox` modules are fantastic, and +I don't think I want to parse Maildirs in bash. "But why not pure +Python?" Well, I'm going to be shelling out a lot (more on this in a bit), +and writing interactive UIs in bash is a lot more intuitive, thanks to +some of the nifty features that later versions of bash have---`read`, +`mapfile` etc. + +The reason I'm shelling out is because two key components to this +client, that I haven't yet talked about---`mbsync` and `msmtp` are in +use, for IMAP and SMTP respectively. And `mbsync` uses the Maildir +format, which is why I'm relying on Python's `mailbox` package. Why is +this in the standard library anyway?! + +The architecture of the client is pretty interesting (and possibly very +stupid), but here's what happens: + +- UI and prompt stuff in bash +- emails are read using `less` +- email templates (RFC 2822) are parsed and generated in Python +- this is sent to bash in STDOUT, like + +```sh +msg="$(./mael-parser "$maildir_message_path")" +``` + +These kind of one-way (bash -> Python) calls are what drive the entire +process. I'm not sure what to think of it. Perhaps I might just give up +and write the entire thing in Python. +Or...I might just scrap this entirely and just shut up and use aerc. +I don't know yet. The code does seem to be growing in size rapidly. It's +about ~350 LOC in two days of writing (Python + bash). New problems +arise every now and then and it's pretty hard to keep track of all of +this. It'll be cool when it's all done though (I think). + +If only things just worked.