[Imap-protocol] protocol version numbers are not a panacea
mrc at CAC.Washington.EDU
Wed Mar 21 22:50:04 PDT 2007
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
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
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
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 --
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
More information about the Imap-protocol