Grepular

I can't imagine how you could build a foolproof (or more importantly, state-sponsored-team-of-experts-proof) time-limited system. Assuming the file is digital, and can be accessed freely, you can make infinite bit-identical copies and fiddle your system clocks to make it work.

You'd need some sort of physical real-time clock combined with the memory storing the material, which wipes it after
a given time. Maybe even a physical medium which degrades over time[3] could work, but that could be foiled by controlling the environmental conditions (inert gas atmosphere to avoid oxidation, cold temps to slow electron migration, etc).

There's a couple of interesting physical-security related links in a comment of mine from the other week: http://news.ycombinator.com/item?id=2932492

My personal approach would be something like providing an incredibly locked-down laptop/netbook (https://grepular.com/Protecting_a_Laptop_from_Simple_and_Sophisticated_Attacks would be a good start), but with additional physical security improvements (battery/big caps wired directly to HDD and RAM via a set of tamper switches[1], disabling all IO ports in software and filling them with epoxy / disconnecting internally) You could then wire in an RTC to the same system, as well as perhaps using a GPS receiver to verify the time (Yes, you could jam/spoof GPS signals if you knew to expect them, but that's still raising the bar).

One final approach would be to have some other trusted party/system which…

Another VPS user here. Linode and Digital Ocean offer great guides to get started. I've basically moved two domains off of the formerly free Google Apps accounts onto my own servers. Overall things have gone well. I like being able to set my own file attachment size limits.

As others have said, a 'clean' IP seems quite important. I've had emails disappear into Google's spam filters despite working previously, as reported by many here[0].

Was tempted by Virtualmin but went with the manual config in the end. Am receiving multiple domains on one server, so it has been a learning curve. Not convinced I've 'learned' a great deal particularly. At least a slightly clearer understanding of the moving parts involved. That's Postfix, Dovecot and Spamassassin, btw. All served over SSL/TLS only, i.e. only IMAPS is enabled in Dovecot.

Tempted to start encrypting all mail as it arrives on the server with GPG, as per Mike Cardwell's advice[1], although I'd have to use mailgate[2,3] with Postfix instead of Mike's Perl script for Exim. I'm also not sure how that would work with search, spam and such. Perhaps it's better to delete mail regularly, saving any files and details needed locally.

Had a slight edge-case issue arise recently - my phone battery died and I didn't have my machine so my mail was inaccessible until home. I've refrained from enabling webmail and think I'll keep it that way for now. Just make sure I have 'a device' with the credentials saved on it on my person when…

I haven't done it, but some years ago a Mike... C.? published a description of how he did email, then. Public/private keypairs. Inbound email would arrive at his server and immediately be encrypted using a public key. It would sit on his server encrypted. When he pulled it off, he would decrypt it at his client using the private key.

If the server was compromised, at that point in time, all the adversary would get would be a bunch of encrypted messages to which the relevant key for decryption was not present on the server.

Just to be clear, this was his keypair, used to keep incoming email at rest on his server encrypted with no local means to decrypt. Irrespective of whether the sender did or didn't use encryption when sending the email to him.

I presume one would want some sort of canary to warn of compromise with respect to further messaging that might arrive or be sent.

Outbound, I presume he was not retaining copies on the server and was using whatever degree of encryption the recipient could handle and the situation warranted.

P.S. I realize this doesn't solve your "you're SPAM" labeling by an ever more differentiating Internet email network.

P.P.S. I'm pretty sure this is it. Site/page design may have been redone a bit. Just if and as this interests anybody -- I haven't taken the time to reread it, right now.

https://www.grepular.com/Automatically_Encrypting_all_Incoming_Email

If the server's capable to decrypt the data, unless you use a trusted HSM that keeps an audit trail, it generally doesn't make sense to encrypt in the first place. Especially with anything resource-intensive. When the server has everything to decrypt the data, the encryption only does the obfuscation, not any strong protection.

Otherwise, if we talk about - just for example - a receiving mail server (MDA) that has encrypted mailbox storage like [1], then it really depends on how much mail you receive. For a typical personal mailbox, where the steady rate is less than an email-per-minute (and usual email size is some kilobytes, not megabytes), encryption overhead is negligible. Such server would sleep most of time anyway.

[1]: https://grepular.com/Automatically_Encrypting_all_Incoming_Email

On the incoming email encryption - yeah, that's in the MTA not the webmail software - having said that, I'm basing what I'm doing off this: https://grepular.com/Automatically_Encrypting_all_Incoming_Email at least partly because Perl is my goto hack-shit-together langiage, I could _easily_ imagine a lot of my cow-orkers choosing to do that in php.

And yeah, I hadn't followed your links, and made poor assumptions about your project. I just briefly skimmed through some of them and I've got a question - have you got a way to protect the passphrase from ending up somewhere the browser can see it? (or, if the decryption is "passphraseless" from the browsers point of view, how do you ensure rogue javascript could pass encrypted data in and retrieve cleartext?)

> the real answer to this

Alternatively, I like the concept of Tor onion services, where the "domains" are acquired in a permissionless fashion. Names are just randomly generated ed25519 strings so there's no squatting and your address never expires. If you want a vanity domain, you just commit compute time to brute force something human-readable. [1] The obvious drawback is that you have to be a Tor client, but if you manage your own DNS, you could use Tor's DNSPort mode as a kind of forwarding target for non-Tor clients on your lan. [2]

1: https://www.jamieweb.net/blog/onionv3-vanity-address/

2: https://www.grepular.com/Transparent_Access_to_Tor_Hidden_Services