MBOX-Line: From mrc at CAC.Washington.EDU  Wed Mar 21 22:50:04 2007
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc@CAC.Washington.EDU>
Date: Fri Jun  8 12:34:38 2018
Subject: [Imap-protocol] protocol version numbers are not a panacea
In-Reply-To: <07Mar21.190015pst."57996"@synergy1.parc.xerox.com>
References: <07Mar20.114847pst."57996"@synergy1.parc.xerox.com>
	<20070320133052.S8455@orthanc.ca>
	<07Mar20.133147pst."57996"@synergy1.parc.xerox.com>
	<1174428749.1318.94.camel@hurina>
	<07E59C2E-717C-4CD3-A668-6059C9F3AC0D@goodserver.com>
	<1174437211.1318.113.camel@hurina> <46008660.2040107@avaya.com>
	<07Mar20.174358pst."57996"@synergy1.parc.xerox.com>
	<F37B003F-C418-4AD4-8579-09BC33D71505@goodserver.com>
	<07Mar21.190015pst."57996"@synergy1.parc.xerox.com>
Message-ID: <alpine.OSX.0.83.0703212201080.24344@pangtzu.panda.com>

On Wed, 21 Mar 2007, Bill Janssen wrote:
>> On a related note, I would not press the point too hard about saying
>> certain software is not IMAP4rev1 compatible. As I recall, a few
>> things became REQUIRED in RFC 3501 that were not in 2060, which was
>> done without bumping the rev # on the protocol, i.e. IMAP4rev2, which
>> would have given vendors a clear goal to work towards, without adding
>> confusion.

The STARTTLS mandate came from the IESG, which for the past several years 
has had a policy of blocking the publication of any protocol specification 
which does not have TLS.  It did not come from the IMAP community.  This 
mandate affects EVERY IETF protocol.

IMAP2 vs. IMAP4 vs. IMAP4rev1 created INCREDIBLE confusion.  The only 
reason why the original IMAP didn't create more confusion is that I 
personally destroyed every copy of its specification and implementation.

Oh, there were good reasons.  IMAP2 was incompatible from the original 
IMAP.  IMAP4 was political to put an end to lingering questions brought 
about by RFC 1203.

IMAP4rev1 came about when it was determined, almost immediately after RFC 
1730 was issued, that certain functionality in RFC 1730 was fatally 
flawed; it had execution ambiguities that effectively precluded its use in 
clients.  The fixes were decided upon relatively quickly, and RFC 2060 was 
issued in record time (only two years after RFC 1730).  Sadly, RFC 2060 
was saddled with the "IMAP4rev1" name because a certain vendor threatened 
to sue.

Today, that IMAP4/IMAP4rev1 discrepancy is a terrible burden.

Do you implement RFC 1730 in your client? If so, how do you deal with its 
flaws, or do you just not use those features (if so, how is it different 
from an RFC 3501 client)?

How many servers that advertise IMAP4 have truly tested their RFC 1730 
support and audited it for security weaknesses?  I know of servers which 
advertise IMAP4 capability, but don't actually implement RFC 1730.

Saddest of all, I've been contacted by people who (in recent years!) 
looked up "the latest IMAP4 specification", determined that it is RFC 
1730, and implemented it.  Oops.  They encounted its flaws, contacted me 
asking how to deal with them, and were very shocked to learn that the real 
IMAP is IMAP4rev1 and not IMAP4.

Now let's consider IMAP's peer protocols:

Email headers changed substantially from RFC 733 to RFC 822 to RFC 2822, 
yet there is no versioning.

MIME has a version, but it is forever frozen at 1.0.

SMTP changed substantially from RFC 821 to RFC 2821, yet there is no 
versioning.

POP has versioning, but POP2 was incompatible from the original POP, and 
POP3 is incompatible from POP2.  There is no hope of an implementation of 
POP2 interoperating with a POP3 implementation, or vice versa.

>> If my memory has served me correctly on that note, then a
>> vendor could have been IMAP4rev1 compliant as of rfc2060 without
>> supporting STARTTLS or disabling LOGIN, and so it is not fair to bait-
>> and-switch by calling those two specs the same protocol rev.
> Interesting.  I was wondering why the server would have to send
> STARTTLS in the CAPABILITIES response if it was a required feature of
> every server.  This seems to answer that question.

The IESG specifically deprecated protocols and servers that did not have 
TLS.  The reason why they did so should be obvious.

RFC 3501 was issued YEARS after the policy was announced, and RFC 2060 was 
one of the last documents issued prior to the announcement.  Ask yourself: 
how can ANY vendor today claim not to be aware that TLS is required in 
Internet protocols?  How can ANY vendor claim that it is "alright" in this 
day and age to transmit passwords in the clear?

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

