[Dovecot] Thinking Outside the Box - Extending IMAP

[Andy Shellam]

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 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 
> 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.
>