In #Mailpile v1, I one of the bits of code I spent the most time on, was exactly that - the TLS validation system.

At the time (it has improved since), Python's standard libraries made it almost impossible to make secure outgoing connections.

And TLS issues were hard to troubleshot. And because we had Opinions(tm), we wanted to sometimes use a TOFU policy for certs, and CA-based security at others. And sometimes we wanted to connect over Tor. But not always.

Thus: the Connection Broker. (2/n)

I've been having a random brainwave today, which I am going to sleep on for weeks (probably months) before I take action.

For #Mailpile v1, we were adamant that we would never provide a hosted service. For good reasons!

I find myself reconsidering, for two reasons:

1. Not everyone wants to host their own software
2. I think I've figured out how to do this in a way that doesn't harm user freedoms

Security does suffer. But how much? Dunno, I need to mull it over. Feel free to object!

It is very easy to write code that *usually* works with an mbox file.

It is surprisingly tricky to write code that *reliably* works with an #mbox file.

Almost impossible, actually, since there are multiple incompatible variants of the format.

I keep coming back to this code and finding new problems with it. That is a good thing, I guess? Making progress...

#email #moggie #mailpile

https://github.com/mailpile/Mailpile
#mailpile coming back

I just published a new blog post on the #Mailpile website, discussing the grant we are getting from #NLNet and what we are going to do with the money: https://www.mailpile.is/blog/2023-05-01_A_Mail_Client_in_Six_Steps.html

The tl;dr is that we are bringing #moggie from "a thing Bjarni hacks on as often as he can", to "a new terminal mode e-mail client which people should be able to use."

I'm pretty excited about this!

This morning I taught `moggie email` to generate e-mails with protected headers, as described in this Internet Draft (co-authored by yours truly):

https://www.ietf.org/archive/id/draft-autocrypt-lamps-protected-headers-02.html

This extends PGP/MIME signatures to cover important message headers, and optionally allows header encryption, including the Subject in particular.

Progress!

#moggie #mailpile #OpenPGP #email

It's kinda fun when you need some sample data, and you know that there is an Internet Draft with your name on it, that contains exactly what you need...

https://www.ietf.org/archive/id/draft-bre-openpgp-samples-01.html

#openpgp #moggie #mailpile

Installing the old #mailpile v1 has become more and more difficult. This is kinda OK, as development there has halted and I don't want new users on that code-base...

But it's also really not OK for those who want to examine Mailpile v1 or worse, have old Mailpile data lying around which they now have trouble accessing.

So today I built and published #Docker images which make it easy to run Mailpile v1 on a modern distro: https://github.com/mailpile/Mailpile-v1-Docker

Feedback is welcome!

@deadsuperhero

Did you give #Mailpile a try?
https://www.mailpile.is/

It has been a good, geeky work-week so far. Not much tootin' been busy.

I did some #devops twiddling for #pagekite. Yay SSL certs?

Made more progress on grant applications for #Mailpile.

Studied #Matter (https://en.wikipedia.org/wiki/Matter_(standard) ) a bit, within the context of #esp32 and #micropython development.

I also had multiple naps and stared out the window a lot going HMM.

Now it's time for another window gazing session, before I dive back into #moggie related #OpenPGP work...

Feeling vaguely proud of the old #Mailpile v1 bayesian #spam filter, which successfully showed me my legit #email from DHL last week, while still sending all the DHL-themed #phishing straight to spam.

This is without using any DNS based blacklists or anything of that nature, just pure content analysis.

Generating keywords that represent message structure and other such things, to better train the spam filter, is one of the more interesting parts of this project. It's fun to see it work!

Having idle thoughts about replication and non-email data (contacts, calendar events) for #moggie.

#Mailpile v1 couldn't replicate. It was a significant limitation which I should probably address this time around.

So many things to think about...

I wrote a long e-mail to #NLNet yesterday, answering questions they have about my #moggie / #mailpile v2 development plans.

How did I come up with X months? It's just how much time I have available! Do I have a roadmap? Not really, but it's in my head? Do I plan collaboration with other projects? Not just yet, I'm being introverted and stealthy still?

Not sure it's what they wanted to hear, but honesty is the only policy. I gave lots of details.

But maybe I *should* publish a better roadmap?

A milestone! `moggie email` made its first SMTP connection today, and successfully failed to send a message!

Successfully, because it correctly gathered and reported the errors.

Sending is easy - making sense of things when they fail, in a way I can present clearly to an end-user, is a bit more work.

The SMTP client design is based on Mailpile v1 code, but rewritten from scratch using #aiosmtplib.

This tool is very close to being useful now.

#moggie #mailpile #email #smtp

moggie email \
--to=accountant@example.org \
--subject='Bank stuff' \
--message='Sorry there is so much!' \
--forwarding=inline,html \
--forward='from:bank date:2022' \
|sendmail -t

Dunno if I'm ever going to want to run such a scary command, but I'm very pleased that it works!

Still on the task list: teach it to sign / encrypt, teach it to speak SMTP, teach it to save sent messages locally...

(This becomes an API for writing #email clients)

#moggie #mailpile

Our applications for #NLNet funding to work on #Mailpile and #moggie have not yet been rejected!

(We made it to round two.)

Fingers crossed.

... and no, ignoring the HTML part entirely is not actually a viable strategy on today's Internet.

There is quite often content in the HTML part which the user needs to read. It's important. And if it looks wrong and wonky, that's just bad UX.

Trying to stick with a plain-text-only strategy that was one of the worse mistakes we made in #Mailpile, it really hurt our usability and made the app look like an unpolished toy.

asymmetry?

What if I also made it convenient to send (and receive) AES encrypted ZIP files?

What if I made it easy (yes, this would require running helper services) for individuals to use their own keys to DKIM sign their messages? And made #Mailpile aware enough of DKIM to classify messages as "unsigned", "signed by organization" or "signed by author"?

What if I made it easy for users to self-host their own TLS-secured web-based chat-rooms, polls or file shares, and send out links?

What if?

As part of my #Mailpile and #moggie work, I am rethinking a little bit what it really means to offer a "secure e-mail client" to the masses.

I think fundamentally, it has to mean making it easier to use the privacy preserving tech we already have. I'm too small to move markets and create new protocols.

So yes, maybe OpenPGP / Autocrypt. Maybe S/MIME. Maybe some clever Tor side-channels...

But these suffer the problem that all participants need compatible clients.

How about some (...)

... by making #moggie index e-mail message-IDs in a way that is backwards compatible with #Mailpile v1, I now have a very basic tag export/import workflow that works!

I need to refine it a bit, to copy over metadata about the tags themselves, but the basics are in place!

I'm not sure there are enough #Mailpile v1 users out there to justify making this more user-friendly than a HOWTO and some CLI commands. But I'm very pleased with this progress.