snoj

That's how I've understood it as well. Secwrap isn't about changing that. Or breaking those rules! Secwrap is focused on how to hide those aspects of messages as well as the body can't (easily) be accessed by unsavory fellows or handed over to third parties. It does this by encrypting incoming messages (headers and body) using a public key provided by the recipient before storing it (e.g. attachment sent to another email address). Or in list form. Email message comes into secwrap SMTP server Secwrap checks config for public key for recipient. If key is found, encrypts entire message (headers and body). Forwards encrypted message as an attachment to another email address or POSTs to a specified url. Note that the original message sent could be a plain text, S/MIME, have attachments or not, it doesn't really matter. Of course this doesn't help when the messages are intercepted before it is encrypted. Nor if the sender is using some sort of service like gmail or whatever MS is calling their's these days. The dead drop enhancement idea is to allow for the sender to encrypt the email message (step 3 above) so secwrap doesn't have to do it itself. The idea of having the sender encrypt the message again with their private key was something to keep out unwanted encrypted messages by requiring "proof" the message was from a specific private key. Thereby allowing the recipient to filter based on knowledge of the sender's key at the server instead of later when offline. (Since the recipient probably wouldn't have the public keys of spammers or other potentially annoying sources the messages.) Does that help clear up my goal? I'm kind of like Richard in that I can really suck at explaining my ideas.

I think I might be missing something too. Since fugu's reply, I've been talking about this github issue (also has the steps I was talking about). That said, signing instead of doing an encryption onion would work too, maybe better.

The data sent to the server is an encrypted onion (see step 1). With the sender using their private key on the outer layer. If the senders public key is known, decryping the data should result something meaningful. This is what I meant by verifying the message can be decrypted.

It would have its place. You can't be online all the time so letting others "dead drop" messages is necessary. https://github.com/snoj/haraka-secwrap/issues/2

A couple months ago there was a hackathon in my area and I wrote a little plugin for Haraka that encrypts incoming mail and forwards it on to somewhere else for storage. I was originally inspired by details of how Lavabit did their encryption and wanting to have something that did a better job. That is, the only knowledge required by the service is a public key. It's slowly being improved when time permits with the next targets being a move away from config files for domain/user/key storage and installation via npm. The code can be found at https://github.com/snoj/haraka-secwrap for any wishing to tear it apart.

Isn't sqlite cross platform? I'd encourage you to use sqlite. It's small and doesn't need much besides the library plus relatively fast. And why re-invent the wheel? Put your energy into making an awesome tool instead.

Thanks guys! I've also started working on making this udev only script. https://github.com/snoj/DrinkAllTheMilk/blob/unification/sbin/datm-udev

From reading the English version site, it seems like he's made a tool that replicates what stub-zones do.

If I've got the wrong place, I'm so sorry ahead of time! A week or so ago I was watching Hak5 1106 and I wondered why the guys didn't use an encrypted volume or loop device to provide an update-able shadow file. So I hacked what I call DrinkAllTheMilk together on and off in the days since then. I'd really like to know what you all think. I'm fairly new to using Linux as a primary OS as well as scripting/programming specifically for it. I wrote the majority of it in PHP as I am most familiar with the language and wasn't wanting to learn Perl specifically at this time. Since I based this off KillAllTheHumans, a lot of the code is lifted or heavily influence by int0x80 and godsflaw. The approach I took to do this was two fold. The first part is a service written in php to listen for signals and then does and undoes the shadow stuff depending on that signal. The second part is a script that is executed from udev that takes care of the thumb drive mounting and unmounting and signaling the php service for further action. These probably could be combined into one udev executed script. At the time, I figured it would be faster for udev execution to split these tasks out. This was especially true when I was matching against the usb subsystem instead of kernal sd* in udev and needed more time to figure out what to do. Thank you! Source: https://github.com/snoj/DrinkAllTheMilk [edit] Some spelling corrections and readability.