ladarlevison

3 ms·

1.
by ladarlevison 9y ago
mm_set is being used. As I recall that pattern was inspired by looking at a libc implementation for memset. The combination of using volatile and the asm("") statements keep the compiler from optimizing away what it thinks are unn
2.
by ladarlevison 9y ago
I disagree. The more layers of abstraction you have, the more places there are for a backdoor to hide. Also, unless you're using OpenJDK, Java means downloading a binary blob which could be hiding any number of surprises, intentional,
3.
by ladarlevison 9y ago
DMAP is designed to work optimally with encrypted message objects. I looked into making it a JSON protocol but JMAP didn't adapt well and was even more complicated than IMAP (if you can believe it).
4.
by ladarlevison 9y ago
It's a monolithic mail daemon that speaks SMTP, POP, IMAP and HTTP, and uses DIME to encrypt messages when they arrive unprotected. It has preliminary support for DMTP and DMAP. Basically it's a replacement for your MTA and access
5.
by ladarlevison 9y ago
You should look at the DIME spec: darkmail.info/spec specifically where it describes account modes. What we have working now is trustful mode, where the server acts a proxy to allow legacy clients to continue working. We're buildi
6.
by ladarlevison 9y ago
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
7.
by ladarlevison 9y ago
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