[Big Mac]

Here's a theoretical scenario I'm wondering about. Let's assume a Linux shared web server. Given the Linux permissions model, could a web hosting company employee log into an IMAP account and read its contents without the owner of the hosting account providing the password to the account?

[besson3c]

IMAP mail messages are stored in a variety of formats, but each of these are plain text, easily readable by the root user. Therefore, the admin wouldn't have to worry about logging in to the IMAP server as that user, as long as they have root access there are much easier ways.

[Big Mac]

Okay, that's kind of what I thought. I guess it's a pretty paranoid thing to be concerned about, but for financially sensitive unencrypted messages (that I know can theoretically be intercepted en route anyway) I will take them off them off the server, just in case.

[Cold Warrior]

A real admin can easily see anything at any time in any place. Those regular employees though should not have root access -- just some sysad account that itself won't (shouldn't) have root's privileges, and which may or may not include enough rights to view customers' IMAP mailboxes (I sure wouldn't set it that way but you never know).

If you're super-paranoid you could always self-issue a certificate authority and personal certificates for digital signing and encryption. That way every email (at least those who use the certificates) resides on the server but is encrypted. This would only work well within a single business. You can't expect customers, other business, or other institutions to use encryption certificates.

[besson3c]

Definitely. The lack of encryption is what would bother me more, especially since it's not always evident. Take GMail, for example. Apparently there is an option to change this, but by default only the logins to the web-based email are encrypted. There is no way of telling what happens between the web server node and the IMAP server backend. Therefore, in general, I always suggest not storing any sensitive information in email unless you have enough control over that server to be certain of these sorts of things.

[Cold Warrior]

The IMAP transactions are encrypted with gmail, and I think that's the only option when using IMAP. IIRC it uses TLS incoming, SSL outgoing. The HTML interface (webmail) defaults to no encryption (SSL) unless you go in and require it by default.

[besson3c]

Originally Posted by Cold Warrior 

A real admin can easily see anything at any time in any place. Those regular employees though should not have root access -- just some sysad account that itself won't (shouldn't) have root's privileges, and which may or may not include enough rights to view customers' IMAP mailboxes (I sure wouldn't set it that way but you never know).

If you're super-paranoid you could always self-issue a certificate authority and personal certificates for digital signing and encryption. That way every email (at least those who use the certificates) resides on the server but is encrypted. This would only work well within a single business. You can't expect customers, other business, or other institutions to use encryption certificates.

An SSL cert installed on the server will encrypt authentication, but it is up to the client to encrypt and decrypt email contents. The only way encrypting email contents would work on the server is if you could guarantee that both sending and receiving servers offered certs, and many don't since this can become an expensive operation with busy SMTP servers.

However, if you want to encrypt your emails I would suggest Gnupg (the open source version of PGP). PGP is a more secure option than the free email certs since anybody can create those and claim to be whomever they want, and Gnupg is free while a commercial SSL cert isn't.

[besson3c]

Originally Posted by Cold Warrior 

The IMAP transactions are encrypted with gmail, and I think that's the only option when using IMAP. IIRC it uses TLS incoming, SSL outgoing. The HTML interface (webmail) defaults to no encryption (SSL) unless you go in and require it by default.

The latter is what I was referring to with the web based client. Most likely it uses SSL incoming, TLS outgoing with standalone clients - this is more common.