Subject: STARTTLS clarification

From: Mark Crispin <[email-masked]>
Date: Wed, 23 Jan 2002 14:32:17 -0800 (PST)

To clarify, imap-2002 changes the behavior of STARTTLS when no server
certificate is installed.

Instead of saying "OK" and then dying on a STARTTLS command, imapd will now
issue a "NO" with the error message "Server certificate not installed" and
continue in non-TLS mode.

imapd on the SSL port (port 993) will continue to die silently since that's
the only thing that can happen in that case.  Of course, an entry is made in
the mail syslog if you know to look there.

The idea is to give an error message indicating the problem (and pointing to
what needs to be fixed) but still allow the user to connect and log in.  If
imapd silently disabled STARTTLS, there would be confusion as to whether or
not the binary was built with SSL/TLS support.

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Jeff Breitner <[email-masked]>
Date: Wed, 23 Jan 2002 18:00:12 -0500

> certificate is installed.

Not to belittle the continuing work in c-client, but do you see 
advantages/disadvantages to imap-2002 performing the SSL/TLS duties as 
opposed to wrapping the connection with something like stunnel?

The reason I ask is that I have modified imap to support virtual domains.  
I'd really like to not have to revisit the modifications any time soon, 
mostly because I've probably forgot what I did and used the documentation to 
dispose of used chewing gum.

-- 

Jeff Breitner
Lead System Administrator
(come to think of it, I'm the only system administrator)
Developers Choice LLC
313-291-5980 x202

---

From: Mark Crispin <[email-masked]>
Date: Wed, 23 Jan 2002 15:28:58 -0800 (PST)

> opposed to wrapping the connection with something like stunnel?

The primary advantages of native support of SSL/TLS in imapd as opposed to
something like stunnel are:
 1) only one process doing the work, and no stunnel/imapd pipes
 2) imapd knows the client and server IP addresses instead of localhost (or a
     pipe).  This is important for some authentication mechanisms.
 3) it's difficult to do STARTTLS with stunnel; either you have to have
     stunnel handle all non-encrypted connections or you have to have a way to
     splice in stunnel in a session that previously did not have it.
 4) IMAP client code needs SSL support anyway, so it has many of the
     mechanisms already.
 5) IMAP client/server code needs the mechanisms to do non-SSL (e.g. Kerberos)
     encryption (not there yet, but coming...)

The primary advantages of stunnel are:
 1) easier to avoid generating a new key for each session.
 2) SSL code in only one daemon.

In most situations, the former set of advantages outweigh the latter.

> dispose of used chewing gum.

This is understandable.  Why is your virtual domain support dependent upon
where SSL is located?  I would expect that most of the virtual domain support
would be in a modified env_unix.c and possibly also tcp_unix.c.

By the way, I need to warn everyone that tcp_unix.c is going to undergo
changes for IPv6.  I am going to try to keep the external interfaces the same,
and as you may have noticed there are some new routines in imap-2002's
tcp_unix.c to move TCP-specific code out of the rest of c-client.  Basically,
the advice is that, if you can, avoid modifying tcp_unix.c for the time being.

---

From: Jeff Breitner <[email-masked]>
Date: Thu, 24 Jan 2002 09:52:12 -0500

>  2) SSL code in only one daemon.

I think this would be most applicable to spop3, where people like to try to 
pop their mail every 60 seconds.  The constant key generation could present 
an interesting loading of the machine, especially on those older machines 
favoured for small-enterprise mail systems.

> where SSL is located?  I would expect that most of the virtual domain
> support would be in a modified env_unix.c and possibly also tcp_unix.c.
>

You're correct, the majority of the changes are in env_unix.c.  If my fading 
memory serves me, I also made some changes to the imap daemon code to help 
assure that the common user for virtual domains stays within the user's mail 
space and can't wander around.

-- 

Jeff Breitner

---

From: Mark Crispin <[email-masked]>
Date: Thu, 24 Jan 2002 12:22:25 -0800 (PST)

> favoured for small-enterprise mail systems.

That's correct, although I've seen IMAP abused that way too, and I've seen the
polling interval as low as 5 seconds(!).

The key word in all of this is "abuse".  A server can ameliorate some of the
harm from this abuse.  Nevertheless, this type of client polling for new mail
is abuse.

Within the scope of client polling, IMAP with a single static session per
polled mailbox doing a periodic command (even a NOOP) is far more scalable
than a regular POP3 (or IMAP!) poll of "open session, check mailbox, close
session".

At a higher scaling level, you need to abolish client polling entirely in
favor of a server-initiated delivery notification protocol.  We're crossing
that boundary now.

IMHO, client based polling is alright for a user's primary INBOX or other
mailboxes with frequent activity.  The cost of keeping a static IMAP session
is probably lower than the cost of creating one when activity occurs.  For
monitoring secondary mailboxes with less activity, delivery notifications are
preferable.

I don't know how to define the boundary between the two cases other than a gut
feeling; certainly a mailbox which gets 100+ messages/day should have a static
session, and one which gets 1 message/day should be notified.  But that's like
saying "I can't define obscenity but I know it when I see it"...