Quoting Andy Shellam <andy.shellam-lists@mailnetwork.co.uk>:
Hi Eric,
SSH tunnelling requires an SSH login though, right?
No. SSH tunneling connects to a service, and that service can require authentication if it so desires. SSH tunneling is just port forwarding via SSH. It can be used to tunnel (and hence encrypt) pop3, imap, smtp, popassd, telnet, ftp, etc.
The client/server applications using an SSH tunnel will carry out their own authentication procedures (if any) the same way they would without the encrypted tunnel.
Even if that's via PAM or other authentication method, it's another set of authentication to set up
No, it uses the existing authentication already in the service, if any, and no additional authentication is needed.
why not keep it all in the same system (i.e. Dovecot?) I
I never moved it out. I only moved the encryption and some session managment out.
wouldn't allow SSH access connections to a public-facing server, mainly for the fact I'd have to disclose the details to my user-base, which
If you are already running IMAP, then you are already exposing this. Tunneling the IMAP via SSH exposes nothing more than the IMAP exposes, except that you are using an SSH tunnel (meaning if they can find an SSH vulnerability, then can crack you).
the majority are non-techies, and it'd be harder to audit logins (there's only my team that login to each server so it's easy to spot if someone's intruding/attempting to.)
No. It may be harder to diagnose problems, but not harder to audit logins. The logins are no different than before, only the transport is.
SSH is for tunneling a connection from the user's client machine to the server which encrypts data over the connection. Why should the average user have to download a piece of software (such as PuTTY), configure an SSH session and tunnel, connect to SSH, then run their usual mail client just to blacklist/whitelist a sender? It'd open up a world of interesting problems for our support guys and is a massive overhead that's unnecessary.
Yes, that would be fairly rediculous. You'd have to have support in your mail client or OS to make it worth doing.
Why would a user logged into their mailbox want to make changes to another user's mailbox?
Hopefully they wouldn't be allowed to. But one user might own multiple mailboxes, and want to manipulate them all. Plus there could be shared mailboxes, etc.
More importantly, why would I, as the administrator, want to let them? If one user owns more than 1 mailbox, then they just switch over to the other account - like myself, my Thunderbird has both my -lists account and my normal account in the same window. It takes one click to switch accounts.
Not sure why you bring this up actually. But there are of course obscure reasons (want to blacklist across all accounts, and not do it manually for each one, etc).
I also disagree with your comment about code security. The fact it requires another system, in whatever fashion, means there's a completely different code-base which could pose even more of a security problem rather than extending an existing code-base which is already well-known (and guaranteed) for it's security anyway? As Timo is offering 1,000 EUR to find a security hole, I very much doubt he'd release an extension that isn't secure. The way it's been suggested, Dovecot would run an external program to set/get the metadata anyway.
Yes, and so, the external program would be another code base not controlled by Timo, so... Well, you do the math.
There are various theories about small vs large code bases. But if you look at security statistics, you will see small code bases almost always win over big code bases, if all other things are held equal. Of course, people can debate that until the cows come home, can you can't really prove it one way or the other, and there are always exceptions.
The comment about another set of authentication was, if you've already established an IMAP connection, why not use it for something else?
That was the whole point of the SSH connection.
If you take it as you said with SSH authentication, the user has to have authenticated via SSH first (to open the tunnel), then
First, it was not my idea to use SSH. I was simply trying to correct your assumption that SSH tunnels would require an authentication. Second, they don't have to authenticate via SSH first, so your assumption is wrong.
the SSH tunnel as well. Using the suggested metadata extension, any IMAP-capable client could be configured to use it with no dependencies on anything else.
As I pointed out, that only addresses issues like black/whitelist, not issues like SMTP via IMAP.
The original question was suggesting that Dovecot could extend the IMAP protocol to do other things (SMTP was an example, as was black- and white-listing.)
Yes, and no solution provided so far has addressed both of those in any real way. The SSH one at least has potential to do so, whereas I see no way the METADATA solution could possible address both of those issues.
METADATA is for storing and retrieving data, not for performing an action. So, yes, it is a possible solution for things like updating a blacklist or whitelist, but not for things like sendmail an e-mail (unless you want to create a batch mechanism for doing so).
Andy.
-- Eric Rostetter The Department of Physics The University of Texas at Austin
Go Longhorns!