100 lines
4.6 KiB
Plaintext
100 lines
4.6 KiB
Plaintext
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.
|
|
|