<<< Date Index >>>     <<< Thread Index >>>

Re: imap/2837: MYRIGHTS not understood by Mirapoint IMAP4PROXY



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