A Hacker's Replacement for Gmail
dbpmail.net
dbpmail.net
What would be useful is a pre-assembled virtual machine image or other form of appliance that allows you to deploy and test a mail server within about an hour or so, without having to duct-tape any of this together yourself.
There at least a couple Linode stack scripts that will do this, but I haven't given any of them a try since last time I checked they were mostly/all Ubuntu based. Dovecot + postfix isn't all that difficult to set up, and there are literally tons of guides all over the place (Arch wiki, Linode, Dovecot's site, etc.) for dovecot, postfix, courier, and anything else you might want. Perhaps the most dumbfounding thing for a beginner is the certificate step...
1) SMTP was developed for unreliable environments. If you have problems with uptime, your incoming email will bounce around for 5 days before it gets dropped. So assuming you can get your SMTP server running one day out of five, you shouldn't be in danger of losing anything.
2) Contemporary daemons like postfix and dovecot have sane defaults, so even a naive default install should be mostly secure. They're also extremely low velocity, so once you set it up there's not a lot of ongoing maintenance.
Another problem is you will have to use a third party smtp server, otherwise your mail will be rejected by a lot of email providers.
* Get a "clean" statically allocated IP address.
* Control your forward and reverse DNS and make them match.
* Set up SPF/DKIM.
* Fill out the Yahoo Bulk Email sender form
That last one probably isn't really necessary, depending on how much email you send to Yahoo.com addresses.
1. Only allow email locally (i.e., via webmail and ssh) - which many would regard as a real pain, but I and the few people who use my server have been OK with. IMAP is very useful with this policy, for batch move/send from outbox folders.
2. Set up TLS to only deliver via SSL
3. Advertise both these facts via SPF (I haven't bothered with DKIM)
You'll get an IP address for your outbound traffic which is "clean", monitored and registered with a ton of ESPs. You can also use Mailgun as a proxy for your incoming mails as well, for spam filtering or custom routing purposes.
Moving to a self-hosted solution (even a US one) offers you more privacy protection options than Gmail/Hotmail, that's for sure. But since physical access is everything, using a US-based VPS provider means there is only a small speedbump between the government and your mail. Using a US-based service like Mailgun, while extremely cool, removes even this speedbump, since they will presumably be forced to cooperate in the same way that Google or Yahoo do.
The best option would be to host your own mail with a VPS with a very strong privacy record, explicit statements about not cooperating with US inquiries, based and hosted in a country with strong privacy protections.
By the way, I still feel that Sendmail has to have the worst configuration file I have ever seen.
That's hardly a rule. You clearly will end up on a blacklist if you host from home or if your IP is already on a list due to previous spam activity, but of you run off a static IP in a decent colo and have a proper PTR record, it is more likely than not to be all OK.
The 90% of inbound spam is still very effectively trimmed off by greylisting, i.e. postgrey if you are in postfix. I've been running my own mail server for close to 10 years now and it's really not a big deal.
Outbound : Use a smarthost.
I host my own mail. I use OpenBSD as my Firewall/Router so it was a simple decision to use the spamd daemon on it for greylisting. The SMTP destination sits on a CentOS machine behind the OpenBSD gateway. I see a spam message maybe once every week or two. I have also used MailScanner to do SpamAssassin and virus scanning of received mail at places I have worked. The spam count went down so far I had people ask me if the mail server was down. A little bit of verification showed we weren't loosing legitimate mail, users were just getting so much spam they thought that was normal.
A smarthost solves your outgoing problem. I can't send direct from my home connection because it is a residential IP and that is going to be blacklisted all over the place. I could use my IPS's SMTP server, hell you could use GMail if you wanted. I however, use a VPS I pay for. My SMTP server logs in (password) over a TLS connection (preshared certificates). It only relays for my mail server because of that.
You don't need to use a well known relay, you just don't relay from a blacklisted IP. Don't leave an open relay and don't send directly from a residential IP block and you probably don't have to worry, unless you start sending spam.
http://www.mxtoolbox.com/blacklists.aspx has various tools to give you a view into how other mail servers will view your hosts.
But this is just for receiving emails (from the outside world), if your IMAP/POP3 server is on the same server as your primary MX you will not have access to emails on the server while the primary is down. You have to find a way to sync your received mail (maildir/mailbox) to two or more servers.
If you decide to implement a backup MX, try to sync your allowed recipients list from the primary because spammers often try to send emails to an MX with a lower priority, and if it accepts all emails for the domain without checking if that mailbox actually exists you could became a source of back-scatter.
http://www.kolab.org/ http://www.sogo.nu/english.html http://www.zarafa.com/ http://www.open-xchange.com/home.html https://www.zimbra.com/
Wow, I'm impressed!
http://www.kolab.org/community/upstream-communities
All of these look fine - I already deploy all the server items - except Round Cube: does anyone know anything about them?
Also I think in kolab it is only used for optional webmail.
When considering if running your own mailserver is practical for you, consider the total cost of ownership; you'll most likely be paying for a dedicated server (or vps, VM, or whatever the cool kids are using these days) which will require staying on top of all the "normal" things; monitoring, backups (and you'll probably want to test them), updates, what blacklists to use, ensuring that /your/ server doesn't end up blacklisted, etc. Unless you've been a sysadmin before and know what this all entails, I wouldn't really recommend it. If you're not part of some bigger org (a hosting co or bigger company), it'll also be harder to get your one-off no-name server removed from blacklists, since this looks just like something Joe Linkfarm would do. I could show you this one really simple trick that a mother found to whiten your server reputation, but...
As far as creating a VM image that sets all this up for you, it's kinda the point that it doesn't exist; mailservers don't work well when run by people who don't really care about them. It's quite far away from a "set and forget" deal. This is why many hackers / sysadmins still use GMail; it's not the best at everything, but it's OK enough at most things that it's the least hassle to use.
That all said, I do agree that it'd be great to have a service which offers both more control for power users (I'd love a mailfilter-style config w/regex support for GMail), better privacy (easy PGP integration, etc), tag support, threading, and normal IMAP support, but I'm not quite holding my breath. This seems like a decent problem for some start-up to solve :) It's not a "sexy" problem, but it's a real one.
Get full disk encryption and be happy.
Full disk encryption and per-user encryption are good steps. But an accidental backup of Pidgin will still reveal passwords that would be safe if they bothered to use platform specific APIs for such storage.
The logs of the conversation can be protected in the same way, so I'm not sure what that has to do with anything. (Although you might wish to keep logs as plaintext, to facilitate backups, if you're not backing up the user's keychain info.)
> No. The Pidgin developers are generally open to, and would encourage integration with keyrings (KeyringSupport).
and then goes on to state that this is difficult to do, since Pidgin runs on so many different platforms, then stating again that they will happily accept such patches.
However, I find it understandable, that the devs don’t go out of their way to support use-cases they don’t feel necessary to support. On their systems, they trust the filesystem and are happy with that, if others don’t have that level of trust in their computer, that’s fine, but not necessarily their problem.
My point about the logfiles was that to store these in the keyring (rather than a key to the encrypted files) would probably annoy the keyring somewhat (at least the poorer implementations thereof), given that it is intended for use with few-byte passwords and not multi-megabyte logfiles.
As far as logs, do what everyone does when you can only store a bit of material: Store your bulk encryption key there.
On top of that, while I wouldn't rely on this cryptographically, the relationship is one-way. Gravatar links email addresses to gravatar images, but it's not intended to link in the other direction, so the same is true for any information stored in the gravatar.
You can use my system to reply with encrypted text to a comment on a blog post without knowing the email address of the person you're replying to, only their gravatar image.
Trusted TLS connection established to gmail-smtp-in.l.google.com[173.194.79.27]:25: TLSv1 with cipher RC4-SHA
Anonymous TLS connection established from mail-yh0-f48.google.com[209.85.213.48]: TLSv1 with cipher RC4-SHA
Would it be considered paranoid to read anything into the fact that they offer ECDHE-RC4-SHA for https sessions, but only RC4-SHA for SMTP connections?
ADH-AES256-SHA (256/256 bits) AES128-SHA (128/128 bits) AES256-SHA (256/256 bits) DHE-RSA-AES256-SHA (256/256 bits) EDH-RSA-DES-CBC3-SHA (168/168 bits) RC4-SHA (128/128 bits)
I wonder why/when the connections end up RC4-SHA instead?
Actually dont see how you can have PFS on DHE either if one of the endpoints doesnt co-operate. You can simply dump the master keys and provide those to the decrypting app.
If I tell you a secret, and you tell someone else ... there's not a lot I can do a about that. If you don't want a third party to be able to hand over your plaintext (or store it) -- don't give them your plaintext (or a means to access your plaintext).
Similarly, if I send you a PGP encrypted email, I can't know if you decrypt that and hand it over to someone else (willingly or unwittingly).
-----BEGIN PGP MESSAGE-----
hQIMA13LrXtLThhwAQ/+LmYMzmaQ3Ui0AF5yRKzCVL/rXzUO3h+cKZVnA2AL/SAR PHcVjgGkm4BT3C8pokeTl+UQPqsBj/i3gteC0zi5QTMyXYxnkCC6915yVGON86BS E5i+pEpXIubnWiKZh81Ik+YARYnTqi+Ea5zW0OAzKmd48FX9m21MK0fKHcdjoYZk 56JaMbTgcSTcW2RIztwQr9EeTnf/XIHsIrhQuOGmZd9kTmbxn9mA+W2AKzgPmv7s Z+RUgEMrbyjNK+s2V/ibPE0CDpBKR6cleWRmAgEknu2Z8QaBIgiv+a64mKMbtL6I H8ZCcM1djgBmXvjfHRwJEvEKEIfJKVQ5Q1SMyskAkWt23CQIbd1toLzx/2e0F0O3 Zjppm+qnBhM6JUOnuc5L42uvZK1+0L3aT99UX5L2xOV8OdqgVto1u+d/Q35LUhNl jjslEKidDxhxFWVHJvVhY/4ogQZIq4WrEpDMoYjRzniECMi779MTl6UnX0vRjVuw 3dbXppozqhB40P7q9Om+ORXGfMrzpIRwABltY6NI5PPjeFgHeNZ/gAFxfWn6INYa mielp57irCYBAVaVIodds2EZNSJ3o8m8A/p4HKbuS8W1qDkU2QY4k+Ns27LY3EQM 0fXx6Ug5INql6vHQpj02W4q4S8A0FipS70WZIH4eWm/aLDWV4PT/0hMoGAhYPgvS lgFoQeoAPeaPJ+Tlb1WX5V7cePBH3EZte+0WcBwlZBBejCBNVAjpyFUG4jMcOv/B IPPa+7IFWjE/1kf7n6e+/OsqDjXWem2j5wJd8R0SJlJk97/VjGDvYAn2mdNCqQ43 /sLRy5oTgEE+kljtFriL5Qfdhkei5UR8RZxV3Yv3J+ARohj7JJovSi0psR9hVI5J BGL2emenig== =Eqf+ -----END PGP MESSAGE-----
It is still better than them not enabling it -- because if we can assume they do not log the data by default, on their own (aka: we can trust google) -- old data won't be accessible once a (theoretical) new warrant arrives.
With SaaS, you don't even have the power to say - Damn your improved version, blast your hip new design, I will stick with the old one, thankyouverymuch. You are always on Version Now.
The more intertwined your relationship and dependence on integration with related products, the messier the ensuing divorce.
This, to my mind, represents a far more inevitable reason to figure a way out of GMail.
(disclaimer: I work for FastMail)
Sure we have folders rather than tags, which means you can't add multiple of them to the same message. Probably the biggest lack is that you can't manage IMAP flags via the web interface. Otherwise, our search is now very powerful (since about March this year) and allows you to build filters that show messages from multiple folders in a single view.
The difficult parts are:
1) UI 2) limits. We have a hard limit of 128 "user flags" because it's in 4 x 32 bit fields in a fixed-width data format. Subtract a few for our internal tooling, and you probably only have 120 you can use for yourself.
Would 120 be enough?
One thing that many older clients did was had $Label1 => $Label5. That was often enough for people... so I suspect 120 is probably fine.
It would be better if you have a more desirable .com domain name. I will probably buy an Enhanced account to use my own domains after free trial.
That said, I like fastmail very much: keyboard navigation, search and overall speed are great!
I have an Enhanced account that is linked to my domain, and an Ad Free account where important mail gets forwarded to. The latter is accessible from my phone, but the former isn't, so if anyone steals my phone they can only see the last few messages I exchanged, and I can just disable an alternative login (similar to revoking an API key) to lock my phone out permanently. I also set up my default personality in the Ad Free account to send all mail through my Enhanced account, so every mail I send from my phone is automatically saved in my Enhanced account and even has the correct DKIM signature.
One question, though, and I'm sure a lot of people are curious about it. You are an Australian subsidiary of a Norwegian company, but your servers are in the US. What happens when an American three-letter agency wants to see the contents of your servers?
We've had a number of US-based law enforcement bodies over
the year try to get hold of our data without going via the
appropriate Australian bodies, and it doesn't work out for
them. In the end, they have always ended up submitting a
request for cooperation via the Australian Federal Police,
as they are required to do, and we respond to that request
in line with Australian law.
Recent revelations mean there may be a few more Australians willing to pay a premium to host mail in Australia.
Also, thanks for your work on Cyrus.
Also, since we're talking feature requests: 1) contacts syncing via CardDav and 2) Calendar.
Contact syncing is vital though. It's really a killer at this point.
I just wish it had an address book and calendar that I could sync.
Those are the things I miss the most from Gmail.
The only problem I have with FastMail is that I've been receiving an increased amount of spam in my inbox.
That's still a lot better than Gmail.
Setting up your own mail server is not a terrible woe-inducing undertaking if you have a working recipe to follow and are comfortable with the Unix command line (e.g. http://www.exratione.com/2012/05/a-mailserver-on-ubuntu-1204...).
Organization and categorization are the sticking point features, given what I've seen of most open source webmail applications. But worth looking around. If you have a basic mail server image, you can keep trying out applications on top of it to see what works for you.
Going beyond that to something with a whole lot more encryption and less of an ability for hosting providers to read your data would really require a product dedicated to that end: that is hard to get right.
How exactly is that any different than it was 6 months ago?
I'm somewhat less concerned about rogue individual sysadmins curiously snooping on my mail, than I am about the NSA's comprehensive perpetual archive.
Exactly where are these convincing arguments that google is sending all e-mail to the NSA? Links? Data? Do you have anything that supports this at all?
There is the telephone stuff that was leaked, which has been well known since 2006 [0]. But, where is this miraculous evidence that google is handing everything over to the NSA?
[0] http://yahoo.usatoday.com/news/washington/2006-05-10-nsa_x.h...
As a "non-US person", I read all the "We disclose user data to government in accordance with the law" explanations from Google/Apple/Yahoo/Facebook et al - as saying "Oh, you want our data from that guy in Australia? Sure, that's 'in accordance with the law' - here's all his email… Anything else you'd like? His social graph? His contact list/address book? His Adwords clickthroughs? His Google Analytics enabled website visits? Oh look, it seems he accidentally put his GPG private key into his GoogleDrive folder - have that too!"
Do you really find it surprising that people outside the US see Snowdon's revelations and the US government's reactions to strongly suggest this is the only sensible interpretation? _All_ the denials/re-assurances we're seeing are of the form "in accordance with the law", then going on to talk about presumed protection against _domestic_ spying, and the 4th amendment rights of US citizens. None of which is reassuring from where I sit.
I still see that "Second, we provide user data to governments only in accordance with the law." glaring out at me from the middle of that denial.
My suspicious mind now reads phrases like " … and frequently pushes back when requests are overly broad or don’t follow the correct process" and "Press reports that suggest that Google is providing open-ended access to our users’ data are false, period", as saying "so long as 'correct process' includes a FISA rubber stamp, and that '(claims of) open-ended access to our users' can only be true if it includes all domestic US users" - then sure, we can say that while still handing over _all_ data on non-US users -it's still _technically_ true.
This is for me, kinda like when someone you thought was a close friend gets married and doesn't invite you to the wedding - nothing's actually changed, but you now view everything differently. Right now I've got that "Oh, _that's_ how it is huh? I guess that explains a few things, I wish I'd known earlier…" feeling - complete with that sense of foolishness for ever having thought things were different.
It might be paranoid - or it might just be pragmatic. Either way, things _are_ different now. I just didn't get invited to The US's wedding, while Apple, Google, Yahoo, Amazon, Skype, TeamViewer, PayPal, eBay, Digital Ocean, Linode, Rackspace, Dropbox, Evernote, Trello, Freshbooks, and a bunch of others all did. Now I have to re-evaluate all those relationships too.
How paranoid is it to wonder if I can trust 1Password any more?
To ask for "Links? Data? Do you have anything that supports this at all?" is asking the wrong question, since the amount that is public is incredibly small (just a tiny fraction would be my guess, but all we can do is make estimates). The question is, Is it reasonable to assume that there is more surveillance? The answer is yes, and to assume that there is detailed email surveillance, either at the ISP level, through backdoors, or through direct cooperation is not unreasonable.
I'd suggest _not_ assuming that might be considered negligent.
So e.g. if you're a US company that has a competitor in China, and you don't want the Chinese company to read your email, it's a sensible precaution to encrypt it.
This made we wonder: would it be possible to actually secure the server in such a manner that the hosting party won't have access to your stuff without your say so ?
I think you can (sort of) do this already with having something like an encrypted virtual server running on the rented VPS. Of course, I don't think this is bullet-proof and you also do have the downside of an additional layer of overhead that comes from further virtualization of your actual server(s).
For me that is an important factor. I rather dislike the fact that in scenarios like Gmail and other providers of their ilk -- access is provided transparently to a third party.
Running your own server can give you a reasonable expectation of privacy. Even in a hosted/colocated environment if you take the time and effort.
If you're going to pull this, you need to know in advance that it's necessary, that's not some minor thing that everyone is going to just do automatically, it's an extra, complicated step it's easy to screw up.
That said, I acknowledge the possibility of compromise in the aforementioned scenario, but once again I don't understand people who always jump to the "I am vulnerable to this narrow threat model, ergo, I should not bother to protect myself against any threat models". Especially when the measures you can take to protect yourself most likely will address the actual threat models you are liable to encounter.
With Virtual Private Servers, it's trivial to do the virtualized version of this through the hypervisor.
mid to high range ones you can though so that might be a workable solution there.
Also, they can still rip the ram out and nitrogen it.
At this point you have pretty much everything on hand to help you fool the customer into believing everything is ok (eg: replace the whole physical machine with a vm...).
Come to think of it -- if you know the hardware in the machine, you probably could replace the machine with a vm anyway -- just mirror the disks and go.
Do you think ovh is any less beholden to GCHQ than Google et al are to the NSA?
Do you think your encrypted partitions and turned-off admin backdoors protect you much against people with physical access to the hardware?
OVH maybe a little more, because at least they're not under the direct auspice of the most megalomaniacal state in the world and will act according to their economic incentives in being a reliable and trustworthy service provider, which in a purely free market would align their interests with my own. However being as they are subject to various hostile state entities that have the ability to exert deleterious effects on that self interest, to the extent that they are forced to, they will cooperate with those entities.
I take action to protect myself from those threats to the greatest extent that I am able in either scenario whilst acknowledging that every theoretical threat model can never be entirely negated, coupled with the fact that at the end of the day, bothering to break through all of my measures and taking that trouble, they would find basically nothing that they were interested in.
I despise the state, sure, I'd like to see it dissolve into something like the system outlined in the machinery of freedom, sure. However in my view, taking any violent measures to expedite this process would both make me as bad as the enemy, and compromise the goal of a better world even if it actually contributed to the downfall of the state.
> Do you think your encrypted partitions and turned-off admin backdoors protect you much against people with physical access to the hardware?
"Much" more than non encrypted partitions and not turned off admin backdoors? Absolutely. Completely and utterly impenetrable to any attack by any means at all? Not likely, I can think of one off the top of my head that would work; freeze the memory, get an image, power off the system and extract the encryption keys from the image to re-mount the partitions. That's 1) not automatic 2) not easy 3) easy to screw up 4) not undetected
Another question - have you done the thinking or got some advice about whether marginally trusting a potentially subvert-able hosting company in a jurisdiction you don't particularly trust (US, UK, and unfortunately for me, Australia) is likely to be a better or worse bet than trying to source a server/vps in a more trusted jurisdiction? (perhaps Iceland? Or am I fooling myself assuming there's anywhere "trustworthy"?)
I think of it like trusting gangs in the thieves guild, there might be some gangs that are ethically more admirable than others, but at the end of the day if it comes down to it, the administrative board of the thieves guild is able to compel any of it's member organisations to act in accordance with its edicts.
So if you're going to take any action that might cause the administrative guild of that thieves board to attack you, it should be a foregone conclusion that the trust of intermediary parties beholden to that central authority is irrelevant.
Arrange your affairs accordingly. If you must deal with gangs of thieves, deal with the better ones, and if you can avoid it, don't. And if, heaven help you, you decide to take action that will paint crosshairs on your back from the central thieves guild committee, your opsec should take into account the full powers that committee is able to bring to bear upon you.
Assuming however it could somehow be pulled off; I guess potential ways to mitigate would be to keep a copy of the exact hardware characteristics of the system you originally have, kernel log on bootup, precise size of disks, chipsets of all the various controllers and compare when the system reboots. It would however be possible though extremely hard to get an exact duplicate of all of these at the virtualisation layer level.
You could call the virtualisation layer in the cpu requesting access to virtualise a subsystem, clock the data bus speeds... There should be some overhead from virtualisation that wasn't there when dedicated...
It's an interesting problem. I'll think more about it.
As for time needed, assume this: The attacker sets up a physical server that can accept the same physical disks as your server (with hotswap), with an additional disk (or ssd) for booting into a hypervisor, sets parameters for this hypervisor to closely mirror that of your server. The attackers server would typically be faster than yours -- it is/can be bought some time after your server was, so this should almost be universally possible.
The attacker boots the vm server, sets everything up; then kills power to your machine, moves the disks over. Your downtime: the time it takes to move the disks (literally).
Good luck differentiating between this and legitimate downtime.
I still think reading the encryption keys from RAM after cooling them with some co2 would be the more likely attack, but it's a fun thought experiment...
That should keep anyone from reading your email (assuming you and other senders are using TLS), but the next problem is that an ISP-level observer can always tell who you're corresponding with unless you use something like mix nets or Tor. And allowing that requires some cryptographic authentication method to distinguish legitimate anonymized senders from spammers without leaking the sender's identity to an intermediary. Having the sender sign the message and then encrypt the message, the signature and anything else that identifies the sender with the recipient's public key ought to do it but I'm not sure if there is any existing software that will actually do that. It might be possible using a combination of PGP to authenticate the sender and SMTP TLS over Tor to actually transmit the message, but the missing piece is for the sender authentication to be integrated with the spam filter.
A malicious VPS provider has access to the machine's RAM, which means they can do almost anything. For example, they could extract your SSH private key and silently decrypt all your traffic.
Is such an attack easy? No. But I could compile sshd with debug symbols and it would be. Even without them it's still possible, just very difficult. Though nothing a skilled employee of a nation-state couldn't do.
But this is a bit irrelevant until you solve the social problem: I'm going to guess that >90% of your contacts use gmail/yahoo/hotmail; so the NSA already has 90% of your mail in their databases anyways- until you convince your contacts to install their own email server.
Indeed. If you want to be secure, you need to keep your email server at home, or in some other location you trust, and make sure all communication on the net is encrypted. That way, if an adversary wants your secrets, they will have to burgle your house.
> That's still a lot better than Gmail.
True, because it takes effort for GCHQ/NSA/whoever to look at your server, which they probably won't do.
> Going beyond that to something with a whole lot more encryption and less of an ability for hosting providers to read your data would really require a product dedicated to that end: that is hard to get right
That's what I'm working on.
But here, what a pleasant surprise. The post is actually describing a real hacker's replacement for Gmail (which coincidentally is almost my setting, except I use mu [1] instead of notmuch). I'll keep it as a reference to send people asking for alternative email hosting.
1. If your provider goes down, you lose mail.
2. If you are conversing with people who are using an insecure mailer, such as gmail, Yahoo, etc (which is probably > 99.9% of all e-mail users), your e-mail is still accessible to the NSA, or to some Fortune 100 advertising company.
3. It's only a matter of time before the "big dogs" in email abuse the position and decide who is and isn't allowed to send/receive email outside of their little oligarchy, either on their own or at the behest of governments.
Like so much else that has been corrupted, we need to scratch the current architecture as too insecure, and build something truly secure for the future. This isn't in the interests of the Googles of the world, and it's actively in the worst interests of the NSA/FBI/CIA, so it's probably the right thing to do.
This is really the core technological issue that has enabled much of the recent mass spying: the Internet really was not designed with security, privacy, or anonymity in mind.
Remember that it started as a research network that was used primarily among academics. Academia is generally a very open and trusting environment. The last thing the inventors of the Internet though of was trying to protect their computers, data, or privacy. We are living with the consequences of that mistake.
The second major cause of this mess is the computer illiteracy and historical ignorance of much of the world's population. They don't understand how they are making themselves vulnerable by sharing so much information about themselves and trusting corporations that provide "free" web services to them. This is slowly changing for the better, as people become more technologically savvy and stories like the current spying scandals and various security breaches hit the news.
As for the technological and security minded among us, particularly those who are just now starting to think about running their own mail servers, what took you all so long? None of the recent revelations should have been unexpected.
The Internet needs a major privacy, security, and anonymity overhaul. If it's not rebuilt with those concerns at the core, they will all remain mostly illusory to the overwhelming majority of Internet users.
Uh, what? We have the tools today. TLS to your mail server, PGP for your email content.
SMTP is already a highly distributed system that is controlled by no single entity. If the big email providers decide to block all the little players, making your own message passing system (with blackjack and hookers) and convincing everyone to come use it is many steps more work beyond just staying on SMTP and convincing everyone to stop using the big email providers. Then at least you don't have to develop new protocols, you don't have to develop new clients, and you don't have to convince people to use them (but still, good luck with that first step).
How about instead we just make email encryption a whole lot easier to use and promote email providers that aren't beholden to court orders (aka probable cause must be demonstrated at a minimum)?
Meanwhile we can work on reforming the security apparatus in the US because 'reasonable expectation of privacy" most definitely includes all the geographical locations I access my email account from, amongst many other things, so should require a warrant.
1. It's likely he's storing emails on the VPS. This puts us back at square one. A third party has a copy of your emails. And we know email does not garner the same privacy protections as postal mail.
2. You need a domain name. That system (DNS), as it is currently implemented (i.e., everyone setting their root zone to servers they do not control), is highly centralized -- few people maintain their own root zone, despite being easy to do. Domain names are susceptible to false allegations copyright and trademark infringement by private parties, not to mention easy censorship by the US gov't. When you lose your domain you lose email. (Though you shouldn't have to: email works fine with IP addresses in brackets.)
So what's the solution:
1. Get a reachable IP (e.g., through ISP) or get a VPS. But if you get a VPS only use it to pierce NAT (how is left as exercise for reader - hint: supernode), not run a mail server. Don't store sensitive data like email on a VPS, or route sensitive data through it.
2. Use IP addresses not domain names. Alternatively, set up your own DNS that is available as a peer-to-peer service, or have your email contacts use a DNS server and root zone you collectively maintain: free domain names that you control. No one can censor your DNS (phonebook), except you.
https://code.google.com/p/k9mail/downloads/list
On a side note, they seem to have just hit v4 two days ago.
Second side note, if you decide to use k9, be sure to turn off the signature under composition settings for each account you add.. it's turned on by default.
That's your main complaint? Google is an advertising company. People buying ads on Adsense don't have access to your personal information. This is simply not true.
Massive government spying revelations based on tapping into centralized infrastructure at cooperative organizations that maintain broad cross-web and cross-mobile profiles of all users, along with their personal communications and data, and you don't see how big this problem really is?
I worry about the same things which is why I'm actually migrating my email to outlook.con slowly (in spite of the NSA etc). She knows my passwords already.
I eagerly read the article to see what alternative to this feature the author was suggesting, so I was surprised to see he's reading the emails with a standalone client...in fact, it's an emacs plugin!
GMail sucks, but a home-made contraption is not the alternative.
Ugh!
All you are saying is that if you aren't looking for a home made contraption, then a home made contraption isn't what you are looking for.
I know how to configure mail servers just fine, but I still wouldn't do it for myself. That's what I mean by "normal".
Or like Heroku: you create your "managed" mail server with a click.
If doing it again I would avoid a Debian based distro. I'd probably use openbsd. And the less ports open the better.
You probably should add SPF records too, if you don't want your outgoing mail marked as spam.
What eventually drove me to GMail was spam. I tried a bunch of different filters, and never found one with good-enough accuracy. Finally I decided that the independence and privacy wasn't worth the time I spent fiddling with filters and dealing with misclassified messages. As far as I can tell, Gmail is 100% accurate. Problem solved.
My experience is I've had a few false negatives and false positives. Gmail is still very good though, and any replacement, if it is to be widely used, needs to solve the spam problem.
If each message had to be separately encrypted for each receiver, would this add much to a spammer's costs? I'm guessing it would, but not by enough to make spam uneconomic. A better solution might be to require that the first email someone sends someone else, unless they've been OK'd by a third party, contains bitcoins to the value of $0.01.
I can confirm that that is not correct. Google regularly flags internal ticket email as spam for one of my larger customers (mail that is sent within GApps). I also see about a 10-20% false positive rate on our various mailings (account setups, billing notices, etc).
That would IMO provide a good base for encrypted client-side apps to build on top of. Open source would better be able address the problem of writing a client once the money needed for hosting and storage is taken out of the equation.
I was thinking something that just manages the problem of being online 24/7 to receive email. This (and possibly sending email) is the only thing that can't be done completely client side. A service like I was thinking of would just accept messages, immediately encrypt them (headers and all) with an RSA key and then dump them into some third party online storage system (maybe sending a notification over XMPP too).
The rest of the email pipeline could then be run completely client-side. I'm talking about doing everything client side: spam filtering, sorting into folders or tagging, running email rules, indexing, and of course viewing and reading email. (A clever filesystem/database would need to be layered on top of the online storage system to manage the state of the pipeline and provide fast indexes.)
For maximum ease of use the client-side app could even be a rich Gmail-like JavaScript app that stores private keys locally and but stores most data remotely (e.g. uses S3 directly via CORS).
This would all allow hackers like us to build interesting (but still encrypted) email services without having to worry about infrastructure. That's something I don't want to manage anyway!
Also the barrier to entry of writing a Gmail clone would be much lower because you could do at almost zero cost. Since you don't have to receive email or manage storage your service would mostly be static JavaScript containing the client-side logic. Most - even all - of the service could just be served on a CDN.
My local cable ISP doesn't allow incoming or outgoing connections to port 25, nor incoming connections to port 80. So at least for now, I can't run a mail server in my home. I've thought about switching to DSL, but then I would take a major hit in speed, in both directions.
Luckily, I have another option. There's a hosting provider where I live (Wichita, Kansas) that offers KVM-based virtual machine hosting. So I'll get a VM there, and if the service is any good, I'll move there from Linode. The pricing isn't competitive with Linode, let alone DigitalOcean, and I doubt that the connectivity is as good, since the server will be in a building here in Wichita rather than a real data center. But I'm willing to try it, in order to support a local business and fight the centralization of the Internet.
https://s3.amazonaws.com/uploads.blog.zimbra.com/wp-content/...
https://www.zimbra.com/docs/os/8.0.2/single_server_install/S...
These tools like exim, horde, dovecot, etc. have been around and worked for decades but wouldn't it be great to have fresh solutions that weren't so ancient and archaic?
I'd definitely contribute to a kickstarter for a good FOSS REST Email server.
| good FOSS REST Email server
Central app that manages the storage, sending (server to server) and receiving (server to server) of email exposed over a rest api
Seriously, what would make a "fresh" solution better than a long standing one, in this case?
Most of the modern smtp and imap servers have very sane defaults.
I run that daily, and Crashplan takes care of the rest. Sure it doesn't save the folder structure and what not, but I'm ok with that.
I used to classify myself as a 'Hacker' and still do when it's something I want to learn more about. Most of the time, however, I'm more interested in just getting the benefits rather than tinkering with the internals. Sometimes, I'm a Hacker, sometimes I'm a consumer.
i.e. something that imports email from gmail WITH labels.
It syncs Gmail labels to notmuch tags.
As I understand it: by default, Gmail treats labels as IMAP folders, which means a standard IMAP exporter will end up with multiple copies of messages with more than one label. The workaround is to only export the "All Mail" folder, and then add support for Gmail's custom attributes, namely retrieving the X-GM-LABELS [1] attribute for each message and then doing something with it (in this case, storing it as notmuch tags).
[1] https://developers.google.com/gmail/imap_extensions#access_t...
http://www.smartertools.com/smartermail/mail-server-software...
Also note that Z-Push is AGPLv3 software. Unless you can get it under another license from Zarafa, you have to release your product with an AGPL-compatible license.
[0] http://www.microsoft.com/en-us/legal/intellectualproperty/IP...
As has been stated time and again, most people don't. The danger lies in politicians, ceo's and other figures of authority who do and can be blackmailed. Rather than a few hackers setting up their own SMTP servers I think a more powerful solution lies in keeping focus on the actual problem, the out of control NSA program.