[Dovecot] Thinking Outside the Box - Extending IMAP
andy.shellam-lists at mailnetwork.co.uk
Mon May 14 20:49:07 EEST 2007
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
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
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
Eric Rostetter wrote:
> Quoting andy.shellam-lists at 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
> 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
> 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
> 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
> 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
>> 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.
More information about the dovecot