Subject: Stupid clients and unsolicited CAPABILITY

From: Rich Graves <[email-masked]>
Date: Mon, 7 May 2001 17:56:37 -0400 (EDT)

uw imapd recently (late 2000 beta? wasn't in beta6) started giving
unsolicited CAPABILITY responses in server greetings and after login:

* OK [CAPABILITY IMAP4 IMAP4REV1 X-NETSCAPE LOGIN-REFERRALS STARTTLS
  AUTH=LOGIN] shemp.unet.brandeis.edu IMAP4rev1 2001.303 at Mon, 7 May 2001
  17:36:25 -0400 (EDT)

At least one common stupid "imap" client (IMAPNotify from vandyke.com)
considers this an illegal greeting. It works if you comment out the
relevant bits in imapd.c.

What are your thoughts on not doing this? The other IMAP servers to which I
made some random telnet connections (Exchange 5.5.2653.23, PMDF5.2-30.4,
Cyrus v2.0.10-044, IMAP4rev1 2000.281 running on ftp.cac.washington.edu)
don't advertise capabilities unless you ask.

Are there any stupid clients out there that assume you don't have some
capability unless you make some unsolicited statement that you do
support it? I understand that you're saving one network round-trip if a
well-behaved client happens to do something useful with the info, but is it
worth it?
-- 
Rich Graves <[email-masked]>
UNet Systems Administrator

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

---

From: Mark Crispin <[email-masked]>
Date: Mon, 7 May 2001 15:13:48 -0700 (Pacific Daylight Time)

On Mon, 7 May 2001, Rich Graves wrote:
> considers this an illegal greeting.

I believe that Vandyke has fixed this bug in an update.

> I understand that you're saving one network round-trip if a

IMHO, anything that causes the fixing (or demise) of a client that does
not handle unsolicited data correctly is worth it.  IMAP should not be
held back by broken software.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

---

From: Rich Graves <[email-masked]>
Date: Mon, 7 May 2001 18:55:47 -0400 (EDT)

> I believe that Vandyke has fixed this bug in an update.

The only publicly available version is dated 1999. I'll send a note, but
losing a client that only does plaintext password is no big loss.

> not handle unsolicited data correctly is worth it.  IMAP should not be

OK, I'll accept that. While ftp.cac seems to be running the last build that
didn't send unsolicited data, I see you're standing by this policy on your
deskmail servers.

You build with neither MICROSOFT_BRAIN_DAMAGE nor NETSCAPE_BRAIN_DAMAGE
defined, correct?

Would increasing the idle TIMEOUT (src/imapd/imapd.c line 41) ameliorate
the MICROSOFT_BRAIN_DAMAGE problem? LookOut Express is popular here. Any
operational considerations against that? We're not low on memory or process
slots.

Increasing TIMEOUT to 90min has seemed to decrease the incidence of another
form of Netscape damage for us... on Windows, Netscape "assumes" that the
socket to the sent-mail folder is always open, and gives a confusing error
if it closes.
-- 
Rich Graves <[email-masked]>
UNet Systems Administrator

---

From: Mark Crispin <[email-masked]>
Date: Mon, 7 May 2001 16:07:17 -0700 (Pacific Daylight Time)

> didn't send unsolicited data, I see you're standing by this policy on your

I forget why ftp.cac is even running an IMAP server.  That server is
definitely not updated.

> You build with neither MICROSOFT_BRAIN_DAMAGE nor NETSCAPE_BRAIN_DAMAGE

Right.  We're still trying to understand the Netscape and Outlook problems
completely.  Entourage has added some additional complications.  What's in
the beta tarball reflects our understanding today, but please keep in mind
that this is tenative and we may change our story tommorrow...

> the MICROSOFT_BRAIN_DAMAGE problem?

I don't know.  The basic problem is that if nothing happens in the timeout
period, the session gets dropped and the user complains about not being
told about new mail.

Unfortunately, Microsoft has told us that they won't be fixing this any
time soon.  We had a meeting, and they acknowledge that it's their bug,
but they have other priorities.

> socket to the sent-mail folder is always open, and gives a confusing error

Charming.  :-)

I wonder how much of an incremental improvement happens between 90 minutes
and 8 hours (480 minutes).

-- Mark --

---

From: Rich Graves <[email-masked]>
Date: Mon, 7 May 2001 21:15:57 -0400 (EDT)

> I forget why ftp.cac is even running an IMAP server.  That server is

Anon imap access to this list, which I've actually used a few times.

> > socket to the sent-mail folder is always open, and gives a confusing error

The stink is it just says "connection refused." No indication to the user
that the email has been sent and it's only complaining about Fcc.

I think a netscape programmer just forgot to check an error code somewhere.
A new connection does get opened, so they can send email without warnings
for another 90 min, but this only happens AFTER a nonrecoverable error.

> and 8 hours (480 minutes).

The summer should be a reasonably safe time to play with this. I'll leave
the undergrad server (we split by user class, not alphabet) at 8 hours and
see if we get a pileup. For that matter, Linux can kill idle sockets for
me, so maybe I'll try 24 hours or even more after Commencement.

FWIW, lsof says 5 of the 333 current undergrad imap connections are holding
files named "Sent" or "sent-mail" open, whereas 65 of those 333 connections
are more than 8 hours old.

It might be instructive to mm_log the first time a file is opened
read/write, if there's a reasonably place to drop such a call. Is there? I
think it's unusual for common clients to access multiple mailboxes in the
same stream. Even Pine opens a connection per mailbox.
-- 
Rich Graves <[email-masked]>
UNet Systems Administrator