The ClamAV dependency concerns me; messages can only be passed to clamd via a plaintext stream. This seems to be at odds with the end-to-end encryption.
The ClamAV library is built directly into magma so plain text messages can be scanned without leaving the magma process space. I'd like to eventually have magma fork and scan messages in an isolated process space that doesn't have access to anything else, but that's a long term goal.
To clarify. We do not use clamd, or transfer the messages to another daemon.
There's a difference-- point-to-point encryption is what you're talking about. Anytime a message is transferred, it's done via TLS, but you can't be guaranteed that at any one point the message is kept encrypted. You can have this today -- just about any MTA has a configuration to only allow TLS connections, and then you can set up an IMAP server to only allow encrypted connections.
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.
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:
Your slightly wrong. Magma uses mmap'ed temp files to hold the messages because ClamAV requires a file handle, or a file name. In theory the message only ever hits disk if memory is exhausted. And at least in theory, is never linked to the file system tree where it can be intercepted. If you know a better way, please submit a pull request.
