Re: imap/2837: MYRIGHTS not understood by Mirapoint IMAP4PROXY
The following reply was made to PR imap/2837; it has been noted by GNATS.
From: Kyle Wheeler <kyle-mutt-dev@xxxxxxxxxxxxxx>
To: Mutt Developers <mutt-dev@xxxxxxxx>
Cc: bug-any@xxxxxxxxxxxxx
Subject: Re: imap/2837: MYRIGHTS not understood by Mirapoint IMAP4PROXY
Date: Thu, 8 Mar 2007 12:42:40 -0700
On Thursday, March 8 at 01:17 PM, quoth David Champion:
>> This is, well, stupid. Not only do they claim ACL support, but
>> QUOTA support as well.
>
> I'm not sure I understand you. I surely don't mean to defend Mirapoint
> (we use them, and I'm not a fan by a long shot) but it is legitimate
> to offer different capabilities when authenticated than when not, no?
True, but do they actually support ACL and QUOTA commands when you're
not authenticated? I doubt it. Essentially, they're *lying*.
I'm philosophically more comfortable with not providing the full list
of capabilities to people who aren't authenticated than I am with
claiming you can do things you can't simply because the client isn't
authenticated. I mean, at that point, why not simply include all kinds
of bogus things in your unauthenticated CAPABILITY response, eh? Like
MAKESCOFFEE, PERPETUALMOTION, and NUCLEARWEAPONS. The reasons for not
including those are all the same: the server doesn't really have them
(i.e. it is lying) and it's wasting bandwidth by claiming that it
does.
> I don't see why they *would* in this case, but to me it seems like
> they're not claiming to support ACL or QUOTA when authenticated. The
> patch seems to be quite correct.
The patch correctly works *around* it. Nothing more.
I mean, logically, they could technically report that they don't
support ANY capabilities to people who aren't authenticated. And I can
respect that somewhat in terms of wanting to play your cards close to
your chest (i.e. for the same reasons you might not want to make it
easy to figure out what brand (e.g. dovecot) or version (e.g. 1.0rc26)
of server you're running, because it gives the untrusted client more
information than is strictly necessary). Plus, it's technically more
accurate: NAMESPACE, UIDPLUS, QUOTA, ACL - these things all cannot be
used by unauthenticated clients, so if you aren't authenticated, it
makes sense to report that you are not capable of that (RFC 3501
provides for CAPABILITY to depend on the state of the communication).
So, you've essentially got two possible, respectable, logically
coherent philosophies on this matter: either untrusted clients need to
know virtually nothing, or letting untrusted (i.e. unauthenticated)
clients know your capabilities doesn't hurt. Sitting in between
doesn't make any sense: if you don't trust your client enough to tell
them that you support IDLE, why would you trust them enough to tell
them you support NAMESPACE? And why would you waste bandwidth claiming
to support things that you don't actually support? There's nothing to
be gained by lying about that.
~Kyle
--
I believe that every human has a finite number of heart-beats. I don't
intend to waste any of mine running around doing exercises.
-- Neil Armstrong