Magma – An encrypted email server daemon
magmadaemon.org
magmadaemon.org
So, this is really cool stuff.
I wish they had a more detailed about page and feature list, but I am still excited about this.
To clarify. We do not use clamd, or transfer the messages to another daemon.
End-to-end encryption is the system whereby the moment the message leaves the sender's hands (phone, desktop, whatever) it's encrypted until it gets into the receiver's hands. This is your OpenPGP/etc. You could think of that as "Signal for email". This is apparently not what Magma is doing.
Here's the relevant line from Github:
https://github.com/lavabit/magma/blob/develop/src/providers/...
You can see that Magma is writing the email message to a file and instructing ClamAV to scan the file. This is actually worse than writing to a clamd socket, since (imho) it would be easier for someone to monitor a directory in a filesystem on a compromised Magma server.
Compare this to how SpamAssassin communicates with ClamAV-- it streams to either the port or socket:
If the MTA also supports some other protocol that affords end-to-end encryption, that's great, but now you need to use special client software that is either proprietary or seriously lacking in features. This is ProtonMail's way of offering encrypted email.
ProtonMail is currently working on a proxy called ProtonMail Bridge that runs on the client and talks to legacy MUAs. All communication between Bridge and the outside world is still encrypted. That sounds like a good idea to me, since I have no intention to stop using Thunderbird anytime soon. It's also probably the only way to bring end-to-end encryption to a large number of people, since it embraces and accommodates the inertia around email instead of arrogantly telling people to switch and wondering why they don't. When it comes to email, backward compatibility is everything.
I'm not sure if Lavavit's Magma can fill the same need; the documentation is rather sparse. But I would gladly run a local MTA if it means I can have my cake (end-to-end encryption) and eat it too (compatibility with legacy MUAs). DIME also looks like a much more open protocol than the vendor-specific stuff that ProtonMail is using.
You mention HTTP, but do you think HTTPS have been as ubiquitous as it is now if people had to install a browser plugin in order to enable it? That sounds suspiciously similar to what South Korea has been trying with their infamous ActiveX plugins for their own national PKI. Nowadays they've moved away from ActiveX to actual browser plugins for Chrome/Firefox/etc, but nobody likes it as long as they have to install even a single plugin. "Compatibility with existing clients" really just means "compatibility with existing clients without any plugins". People don't like installing plugins.
Maybe a few years from now, every well-known email client from Outlook to Thunderbird to SquirrelMail will support an E2E encrypted email protocol (either a modified version of SMTP/POP/IMAP or a brand-new protocol) out of the box. Then, and only then, I think it might have a chance to become as successful as STARTTLS has been.
The worst part is that they could easily allow interop and implement proper features in the client. Too bad they don't care and the competitor(s) (is there anyone else than Tutanota with a full e2e impl?) don't care about the users either.
I worked for a competitor a while ago, was ruined by a relatively incompetent CEO. The team is still fiddling with various small projects related to the field, but creating a proper solution without funding is quite hard, as it's a very extensive, challenging project.
Source: I'm a Python/Ruby/Node/VB/C/C++ dev
(I started my career shipping C code, FWIW.)
Oh boy, I'm starting to grow weary of folks tirelessly thumping this mantra. It's patently absurd.
Heck, most of us, yourself included, started off with C... it's just how it was/is taught.
Perhaps your C skills get rusty without use, or perhaps you're not a bit-twiddling magician, but you can still read it, and therefore think about it, and therefore write it.
It doesn't limit the pool of contributors... quite the opposite.
Now, if you want to have a debate about a better choice of language for other reasons, that might be fair game... but to imply there's a shortage of C developers is just absurd.
Most of the Python and Ruby developers I know are not comfortable writing C code.
More importantly, there's nothing in the world more dangerous than someone who knows just enough to get something working in C.
C is a harder language to learn than Ruby, Python, or Javascript. Unlike any of those languages, to write in C you have to constantly keep object life cycles, memory hierarchy, and memory layout in mind. Most of the standard libraries of Python or Ruby --- even simple string manipulation --- are idiomatically written and rewritten by hand in C. Even experienced C programmers forget, routinely and to calamitous affect, how machine integers work.
Writing something in C reduces the number of programmers who can contribute to a project.
And that reduction is going to get worse and worse over time. When I started my career, if you were going to ship code to clients, C was the industry standard way to accomplish that. A giant chunk of all working programmers used C as their daily language. Today, only a small minority of programmers will ever once write a production C module.
This is completely untrue. My experience with Rust is that many, and likely most, Rust developers came to the language as their first systems programming language. That's one of the main reasons you see so many questions about the borrow checker: it's codifying existing best practices in C and C++, but most developers coming to the language aren't aware of those practices in the first place.
Speed is almost never the primary concern with email, which is a world full of rate limits, throttles, spam filters, transient failures, tarpitting, blacklisting, inbox placement delays, etc.
So the solution is to use the simplest tech stack possible and put the vulnerabilities in there yourself? If you're using this software, you have to trust somebody. I think most people would sooner trust that Java isn't backdoored than trust that this new C project doesn't have any buffer overflows or memory leaks.
With magma I've taken the approach of trying to limit my dependencies to the kernel, and libc. Anything else I use is bundled and thus gets tested extensively for leaks, overflows, etc. That doesn't mean bugs don't exist, but it does mean if they exist, then the source is there for you to inspect and fix.
In my mind technical analysis is incomplete at finding 100% of intended or unintended flaws in either system, but the DIY approach allows for trust in the authors whereas a deep stack makes attribution muddy.
You would have to scan the C project for buffer overflows and memory leaks in addition to scanning the tons of C libraries that it uses[0] for buffer overflows and memory leaks (note that openssl is in that list, among other massive libs). This is not even taking logic errors into account. There is simply too much to consider all at once, and being in C just makes it that much harder have a reasonable sense of security.
You're also implying that it's easier to spot intentionally backdoored C than intentionally backdoored Python, Go, Java, etc, but I have no reason to believe that that's true. Furthermore, the number of eyes that have been on those projects is far higher than the number of eyes that will ever grace Magma.
[0] https://github.com/lavabit/magma/tree/develop/lib/archives
JMAP is a vaguely IMAP compatible protocol, in that the mail storage is probably just Maildirs or whatever (with some indexes to make it fast). It is not a complete re-design of how email works. Encryption is just in the network layer between client and server; the server, if compromised, would compromise the mail (unless other encryption features are layered on top, as in the current email standards). That's a perfectly reasonable design decision, given how email has always worked, and the problems inherent in pushing encryption to the client...particularly if the client is a web browser.
DMAP is not merely "IMAP with JSON over HTTP" (JMAP isn't just that, but that's a reasonable enough short description). It's a fundamental redesign of a mail client protocol. Again, I haven't read the formal spec or anything, and there is no source for DMAP yet that I can find in the repo (DMTP is there, but no DMAP), but given what it's promising, it can't possibly just be layered on top of IMAP without significant changes. DMAP seems like a very long-term project; maybe years away. I don't know if there are any implementations, yet.
And, JMAP is so new as a public thing that I would guess it wasn't on Levison's radar until recently. It recently began the formal standards process, which is cool. But, it's also not really got any complete implementation (just a PoC proxy and an incomplete implementation in Cyrus with plans for Dovecot to get support at some point, too).
So, I think it boils down to a few things: JMAP doesn't solve the problem DMAP sets out to solve (which is end-to-end encryption with at-rest encryption on both ends), JMAP is also very new and has no production-ready implementations on client or server, and these are both open sourcing of projects developed as commercial tools (JMAP comes out of Fastmail development, DMAP comes out of Lavabit and Silent Circle).
Also, this does appear to have an HTTP server...so, probably something quite similar to JMAP, though certainly not talking the same protocol (since it pre-dates the publication of JMAP details). It could probably be made to support JMAP without a huge amount of work, since it already supports IMAP and HTTP.
I was under the impression that it was more or less running live at FastMail but I admittedly never dug into the details.
It combines outgoing (SMTP) and incoming (POP, *MAP) functionality, so it would be like using Dovecot and Postfix (rival mail server products) together.
It requires that you have a relational database (the documents describe MySql) and a key-value store (the documents describe Memcache) to support it and the documentation suggests it's designed for Linux (specifically with instructions for CentOS, which is a Red Hat distro). A mail server is generally installed on an "always-on" computer connected to the internet-connected network.
Note that even though it's "designed with security in mind", I don't see any mention of a security audit on either the linked page or the GitHub repo.
Are you Just Some Person(tm) with some technical chops, who otherwise isn't going to attract a lot of unwanted attention?
Are you someone who does things that might annoy others enough to make them want to mess with you? Who are they and how annoyed might they become?
Are you an aspiring Ed Snowden?
Do you have confidence in your skill set to 'know' that you've configured this and everything else on the machine securely? If so, do you watch the disclosure lists for vulnerabilities, enforce configuration, audit and monitor, and generally stay on top of these things?
Etc. Again, I'm really not trying to be overly pedantic, but there's just no such thing as 'secure' without qualifying it with a description of 'against what'. Similarly, what's 'reasonable' for me - someone who's worked with this stuff my entire career - is absolutely bonkers to suggest to a non-technical person.
Anyway, all that said, this doesn't look ready for prime time to me. I'm certainly interested in it, and might play some when I get a chance, but even after it looks ready for use, I'd likely wait for a while to see what other people find before deciding to use it in production. My mail system runs Postfix and Courier with various support systems. Mortals can indeed run this sort of setup, if they're willing to learn a bit. It isn't rocket surgery, but it takes a bit of work.
1. Someone who has some servers and a little tiny bit of technical knowledge. Or, to be exactly, I happen to already run Postfix+Dovecot+rspamd for my email.
2. Someone who is interested in personal email security/privacy, in particular in terms of both in-transit and on-storage encryption. I can't realistically watch for every CVE and patch all the holes on the day 1, so I would always love something that would let me trust my servers and network less.
I don't have any specific threat model or a designated adversary. I just see "hey, there's a some new stuff that looks promising" (this submission) and wonder if it could improve my life. However, the documentation is sparse, or, I'd better say, nearly non-existent (or I'm looking at a wrong place). So, asking if someone had already spent time to evaluate or had actually used that and can share their experience is a logical choice.
Thus, I just wonder - is Magma for me, can I run a secure personal email server with it? Like, use it to replace my Postfix+Dovecot system? Can I expect it to be no less reliable than my current setup (which is just your average run-off-the-mill configuration, documented in every other "how to set up your own mail server" article)? Is it correct to expect it to add some value in terms of security? What the exact those improvements would be?
Beyond that, I tend to be pretty conservative with things like email. What you currently run, assuming it is configured correctly, is solid; I'd personally be hesitant to replace it until other folks have bled over the inevitable first bugs and it has been in use long enough for people to learn how to operate it, figure out any weirdness, etc. At the least, you'll be skipping what will probably be several point releases right after whenever they actually call it done.
TLDR; if I were you, I'd hold off. (And am personally holding off.) I'm very interested in this, in theory, but even though I am technical, I'm not a cryptographer or a security researcher, and even if I were I don't have the time to audit it. I want those folks to beat it up before I wade in.
[1] Nothing wrong with that in principle, but combined with the jagged edges, it makes me wonder how much attention any grafted code is actually getting.
Basically just the right inline asm. But the project as a whole is a bit of a mess, multiple 'memssets' will not do anything to make things more secure than just one.