Hacker News Reader

Comment by andybak | Hacker News Reader

No reason not to use a 3rd party IMAP/POP and still use the Gmail front-end.

Best of both worlds.

There were multiple reasons right in his post. Including the actual support options like being able to call someone at 3am. And the service level agreement that states it has to stay up or you don't pay for it. And the regularly scheduled backups that you know are occurring. Gmail has none of that.

If you're really only using the frontend you don't care, you have an alternative if it stops working.

Using Google Apps, all factors considered, seems to be less reliable than the old free Gmail. (Since Google can't pull the plug on you like it does to its paying customers, like this case)

The thing is, it's not just the frontend. Gmail's backend has outtages, too. Often in conjunction with the frontend. Sometimes just the IMAP/POP goes down. In any of those situations, it'll be fixed eventually, but you have no support available to you to let you know what's up or to report issues to if its something only affecting your account.

Google can easily pull the plug on any Gmail account they want. It says so right in the terms of service. You have no guarantee of service or access to your data. Even higher profile reporters have had access to all their Google data (gmail, calendar, contacts, documents, google drive, etc) disabled for having what appeared to be client payment data in a single Google doc. They were only able to restore it after a few days because they had some connections.

You're just adding more points of failure.

I thought that a single point of failure was a bad thing. Sure you might want to only have a single place where things can fail, but if that failure is catastrophic...

No, adding more points of failure doesn't make the first potential point of failure more fail-proof, or anything like that.

If adding a new layer (gmail) creates a new point of failure without creating any new resilience against failure, you're putting yourself into a bad position.

Think about failure like resistance. Points of failure in parallel gives less overall risk of failure. Points of failure in serial (like adding a front-end) gives greater overall risk of failure.

"Single point of failure" means a point at which a failure effectively breaks the entire system or workflow. A system may have many SPOFs, which is worse than a single SPOF, which is, in turn, worse than no SPOFs (that is, the desired case is no single failure kills forward progress).

Yes, extra points of failure may include:

- Having webmail which is not protected with two factor authentication

- Enabling POP/IMAP which also does not have two factor authentication

This is true, but sometimes be introducing a new risk (point of failure) to the system, you get the ability to route around another. In this instance, separating POP and Gmail gives you the ability to route around Gmail when it's down.

Not really if you can also use the other account directly if Gmail were to fail.

The polling interval for POP (there is no IMAP) can be up to an hour, which I find sufficient reason not to be happy with that approach.

there is no IMAP

What do you mean?

The Gmail mail fetcher that allows you to use non Gmail accounts in the Gmail interface is POP only

https://support.google.com/mail/answer/21289?rd=1

Why not forward from Rackspace, that's what I do.

This

Forward to your firstname.lastname@gmail

Configure SMTP

Configure filters so you have a folder for company email

problem solved

One minor annoyance with that is that it breaks Gmail's SPF lookups as Rackspace does not do SRS [1] (last time I checked).

[1] http://www.openspf.org/SRS

With, perhaps, the disadvantage that now the NSA can choose the easiest target to mine all your email from - if Google pushes back on a request, they can just go to RackSpace instead.

It's a difficult compromise between availability and security/privacy. I want to be able to get at my mail from all my devices via any Internet connection, but. I still want privacy from dragnet intercept-and-record-everything surveillance.

My current plan - a mail server in the least US influenced jurisdiction I can manage, automatically encrypting all (unencrypted) email to a public key of mine, the forward the encrypted email to a gmail account. I can decrypt mail at the client on my phone/tablet/laptop/desktop, but I lose a lot of mail searchability this way.

Considering that they have an open line to Gmail, if you have stuff in Gmail, the NSA isn't going to need to worry about going to Rackspace.

Why not set up your own SMTP server that only accepts connections from rackspace. Then forward to aaa.bbb.ccc.ddd:55525.

Reply on news.ycombinator.com