SSL wrapped sieve support (ala "imaps") for timsieved [LONG]

Ben Poliakoff benp at
Tue Jun 17 14:47:23 EDT 2003

* Rob Siemborski <rjs3 at> [030617 10:49]:
> On Tue, 17 Jun 2003, Ben Poliakoff wrote:
> > Given that in many environments end user interactions with sieve scripts
> > are mediated by web based interfaces (that don't easily lend themselves
> > to authentication methods like SASL/GSSAPI), how much work might it be
> > to implement a separate SSL wrapped "sieves" port for timsieved?
> timsieved supports STARTTLS.  Why do you need a separate port?

I need PLAIN authentication on my server (because I need to support many
clients, not all of which support SASL/GSSAPI or STARTTLS), but only if
it is done within an SSL tunnel or within a STARTTLS session.  I don't
want to allow plaintext authentication if the network traffic is clear

Cyrus imapd can run on port 143 (imap) and/or 993 (imaps).  In either
case with "allowplaintext: no" in imapd.conf, PLAIN authentication
is available if the connection is "imaps" or if the client is using
STARTTLS (plaintext+TLS).  This kind of flexibility is great.  With it I
can support a larger number of clients, all authenticating "securely".

When it comes to sieve, I'd really like to be able to do the same sort
of thing.  Right now to support a cgi/web based sieve client (like
websieve, easysieve, squirrelmail's sieve plugin, or Horde's Ingo -
none of which support STARTTLS) I need to set "allowplaintext: yes" in
imapd.conf.  And then if I want to protect the traffic between my
cyrus-imap/timsieved server and my webmail server I need to run two
instances of stunnel:

- on the server that runs timsieved I use stunnel to wrap port 2000 and
  make it available on another local port (say 2001)

- on the webmail server I need to run stunnel once more to decrypt
  traffic from port 2001 on the imap/timsieved server and make it
  available on the local server on another port

It's awful, but it works and I'll do it because I don't want that
traffic running across our network in cleartext.  But of course now I
have clients that might start accidentally doing cleartext imap
connections, since that's now allowed (where it wasn't before).

If timsieved supported an SSL wrapped port ("sieves" for lack of a
better identifier) I could cut out one of those stunnel instances and I
wouldn't have to set allowplaintext to yes in imapd.conf.

Obviously it would be really nice if we had a crop of web based sieve
clients that supported STARTTLS (and I'm investigating what it might
take to patch the PHP/Pear Net_Sieve class, used by Horde's Ingo, to
support STARTTLS). 

But in the meanwhile it would be great if we could enable web based
sieve clients without turning on cleartext authentication for entire
cyrus-imap installation.

I think that summarizes my points.  Sorry for the length of that post,
but I wanted to make myself as clear and unambiguous as possible.


Ben Poliakoff                                       email: <benp at>
Reed College                                          tel:  (503)-788-6674
Unix System Administrator      PGP key:
0x6AF52019 fingerprint = A131 F813 7A0F C5B7 E74D  C972 9118 A94D 6AF5 2019

More information about the Info-cyrus mailing list