[Dovecot] Thinking Outside the Box - Extending IMAP

[Eric Rostetter]

Quoting Andy Shellam <andy.shellam-lists at 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!