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 18:37:47 -0700
On Thursday, March 8 at 02:53 PM, quoth David Champion:
> Anyway, you seem to be assuming that Mirapoint's server does not
> support QUOTA or ACL before login, but I'm not sure why that
> assumption is valid.
Well, there's a couple reasons. The most obvious is that ACL commands
are only allowed in the authenticated state (IMAP communications can
be in one of three states: not authenticated, authenticated, and
selected), according to the ACL RFC, 4314. See the table in section 4.
(I'll explain more in a moment.)
But I also find it hard to imagine that a server author would go to
the trouble of implementing SETACL, DELETEACL, GETACL, LISTRIGHTS, and
MYRIGHTS (which is not a particularly trivial set of commands) for the
anonymous user but would then claim the commands were "unidentifiable"
for an authenticated user. If they really had supported them for only
certain users, I would think a NO response would be more appropriate
than a BAD response.
> Is authentication necessary for mailbox access? Does anonymous
> access require login as an "anonymous" user? Again, I could be
> wrong, but I didn't think so.
Strictly speaking? Mailbox access, for the most part, requires the
server to be in the authenticated state. RFC 3501 (i.e. the IMAP RFC)
says that the only commands allowed in the "not authenticated" state
are CAPABIILTY, NOOP, LOGOUT, STARTTLS, AUTHENTICATE, and LOGIN.
(Extensions may, of course, define more that can be done while not
authenticated, but I'm just talking basic IMAP for the moment.) Doing
things like SELECT, EXAMINE, LIST, and so forth all require the
authenticated state as a minimum. And, as I mentioned before, ACL
commands require the authenticated state as well.
So the question then becomes "how does one get into the authenticated
state?" Obviously, you can do so by using either the LOGIN or
AUTHENTICATE commands, but what about anonymous users? Well, here's
what the IMAP RFC has to say:
Server implementations MAY allow access to certain mailboxes
without establishing authentication. This can be done by means of
the ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. An
older convention is a LOGIN command using the userid "anonymous";
in this case, a password is required although the server may
choose to accept any password. The restrictions placed on
anonymous users are implementation-dependent.
Once authenticated (including as anonymous), it is not possible to
re-enter the not authenticated state.
The phrasing they choose is a little wonky, but that says (to me) that
you can have anonymous access, but you need to do it by
"authenticating" (a poor choice of words) as the anonymous user in
some way. Someone could argue that their means of establishing
anonymous authentication is through "connection" (i.e. everyone that
connects is insta-magically authenticated as an anonymous user), but
if that were true, then the server would be required by the RFC to
greet the user with the PREAUTH response, which it didn't do.
Anyway, yes, ACL at least, and probably QUOTA (though the QUOTA RFC
doesn't say anything about authentication), only makes sense in an
authenticated state, and the Mirapoint server is giving the client
every reason to believe that it begins the connection unauthenticated.
Thus, claiming ACL or QUOTA support at the beginning is misleading at
best and flat wrong at worst. I suppose it's possible that Mirapoint
implements ACL and QUOTA support for some users and not for others,
though I (for no good reason) rather doubt that. But either way
there's no point in advertising it up front if they're going to insist
that IMAP clients must automatically check CAPABILITY *after*
authenticating. No matter how god-like their implementation of ACL and
QUOTA for *some* users (assuming they have one), advertising them
before authentication is wasting bandwidth (admittedly, not very much)
for all those users who are not sufficiently deserving of ACL support.
~Kyle
--
In any conversation where only one side may be argued, we
instinctively assume that those who publicly defend the official
position are motivated by ideology and not by an interest in truth.
The outlawed position is then assumed to be true, and wins by default.
-- Fr. Andrew Hamilton SJ