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

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