Hi Eric,
SSH tunnelling requires an SSH login though, right? Even if that's via PAM or other authentication method, it's another set of authentication to set up, why not keep it all in the same system (i.e. Dovecot?) I 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 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.)
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.
Why would a user logged into their mailbox want to make changes to another user's mailbox? 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.
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.
The comment about another set of authentication was, if you've already established an IMAP connection, why not use it for something else? If you take it as you said with SSH authentication, the user has to have authenticated via SSH first (to open the tunnel), then authenticates via IMAP. Sure if your IMAP component recognises an SSH tunnelled connection, and doesn't require authentication for it (not sure if Dovecot can be set up like this), then that closes the door for using your mail account on a different machine without having to set up 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.
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.)
Andy.
Eric Rostetter wrote:
Quoting andy.shellam-lists@mailnetwork.co.uk:
I disagree about SSH.
Good for you.
Firstly, how do virtual users fit into your proposed setup?
You can setup a ssh tunnel on the server on any port. The user then sets up to connect to that port. The authentication can be done anyway you want, or not at all. We're not talking ssh logins to the server, we're talking ssh tunneling.
Secondly, as a service provider to the general public, the absolute
LAST thing I want to be doing is opening up SSH access to my servers.Why? An SSH tunnel can be useful, and can increase rather than decrease your security.
Now, if you meant logins, that would be a different story.
Mark has a valid point in that you have to connect to the server via IMAP to get your mail, why should you have to have a second protocol to do other things with the same mailbox?
Because some of these things may not involve the same mailbox? And because it makes for several smaller code bases which are then easier to secure, audit, debug, etc. (instead of one massive code base that is harder to secure, audit, debug, etc). And because then the authors only need to know and understand one protocol, instead of trying to know and understand any number of protocols that they may not use, have any interest in, etc. And so that those who only want 1 protocol can install only that protocol, and not have to worry about all the others? And, well, you should get the idea by now.
And why worry about a whole second set of authentication when you've got a pre-authenticated connection ready and waiting?
That was what the SSH connection was about I think.
I agree it's not portable, and not ideal (ie. look at M$ Exchange's handling of custom server features), but Timo's suggestion of using the METADATA extension may strike the ideal balance between an extensible feature and the IMAP standard.
Yes, but it only would handle some situations (maybe whitelist/blacklist) and not others (like SMTP) so it isn't what the original question was about really.
Andy.