[Dovecot] Is this really a user agent issue?

[Phil Howard]

I think this issue has been entirely misunderstood.  Have I explained it wrong?

2010/12/22 Karsten Bräckelmann <guenther at rudersport.de>:
> On Wed, 2010-12-22 at 09:34 -0500, Phil Howard wrote:
>> 2010/12/21 Karsten Bräckelmann <guenther at rudersport.de>:
>>
>> > Creating the new mail folder is entirely on the IMAP server side. The
>> > MUA (Evolution in your stated case) is irrelevant. If the creation of
>> > the new folder fails, it is a server side problem.
>> >
>> > However, once a new folder has been created (server side, mind you),
>> > Evolution won't know about that folder until it is restarted. Probably
>> > the same with other MUAs, too. In the worst case, restarting Evo twice
>> > should show the new folder.
>> >
>> > (That is assuming you are not limiting your MUA to subscribed folders
>> > only, or, as IIRC is the default, deliver auto-subscribes the user to
>> > the just created folder.)
>>
>> Then I would call this a user agent issue.
>
> You snipped the part of your OP where you stated that dovecot deliver
> fails creating a mail folder. This is NOT an MUA issue.

Then whose issue it is?  There is clearly an issue because an existing
folder cannot be accessed by this MUA.


>> If IMAP provides a way for
>> the user agent to discover the folder already exists, then the user
>> agent should do this, at least if an error is encountered when trying
>> to create it.  Evolution clearly does not (or doesn't act on knowing
>> if it does).  Other user agents, I don't know.  But it is simple
>> logic:
>
> There is a way for the MUA to discover folders existing, LIST. Existing
> on the IMAP server, mind you, again. So this is not an MUA limitation.

But it would be an MUA issue if the MUA fails to do LIST after an
error from CREATE or whatever command it is.


> Also, MUAs don't care about the full list of folders, if they are in
> subscription mode. In that case, they ask for subscribed folders, LSUB,
> not all folders.

It was not in subscription mode.


> Which method do you use? (That's a client option.)

Whatever it starts out as.  I don't do subscriptions because so far it
hasn't needed to do that.  I don't want a subset of folders.  I want
all folders.  How would subscription help there?


>> if (create folder $name succeeds) OR (folder $name can be accessed) then
>>         set up local reference to folder $name
>
> This is unrelated. *sigh*  In your case, the creation is server side.
> And yes, unless you use subscription only, Evo does exactly that on the
> next start -- ask for all folders on the server.

The point is, if it tries to create a folder, and there is a failure,
and because a developer should know and understand that an existing
folder is a cause for a failure of a create operation, it should try
to distinguish this.  A user expects the folder to show up in the list
when created when there is no error.  If the folder already exists,
then there is no valid reason to not put that folder in the list now,
just as a successful create would do.  Since the protocol apparently
provides no means to reflect this situation accurately, the MUA needs
to have some means to get access to the existing folder.  Restarting
the MUA is not an acceptable means.

>
>> else
>>         report error about creating folder $name
>> endif
>
> Impossible. The error creating the folder occurred on the server, during
> delivery, which does not even need to be doveot deliver but any number
> of other MDAs.

No.  The delivery successfully created the folder.  The error happened
later when the MUA tried to create the same folder, due to the MUA not
being aware the folder had been created during delivery.  But in the
case of Evolution, because of that failure in the create operation, it
did not allow any access to that folder.  The existing folder it tried
to create did not get added to the list.  It could have been had the
logic I described been used.  Or it could have been had IMAP provided
for a better explain error (more often referred to as "an exceptional
condition" in the classic programming methods I originally learned,
rather than a pure unexplained error).  Still, the MUA could get
around that with the suggested logic.


> Either way, no client needs to be running while mail is being delivered,
> and often is not. The server just does not even tell the client about a
> failure, even *if* it potentially could know about that. This was purely
> a server-side operation and failure, and the client, any client, is not
> going to be informed about it.
>
> Only a successfully created folder will be known to the MUA during the
> LIST command.

If the folder was created by delivery of mail after the MUA was
started, and then how do you think an MUA should become aware of that
folder ... other than by restarting the MUA which is not an acceptable
requirement.


>> That, of course, depends on IMAP having a means to detect if the
>> folder exists (even though the folder was not given in a previous list
>> of existing folders).  Trying to open it should be a way to do that
>> test.
>
> Yes, the IMAP server does detect new folders.

Is this a detection in the sense that the server is notified of the
new folder, or simply a context of knowing because a component of the
server (deliver) created it?


> "Trying to open it" sounds like a client action -- in which case it is
> just wrong, because the client cannot even try opening something it
> never knew before existed. Other than brute-force trying all possible
> char combinations...

When the user is asking for the folder to be created, the user
provides a name of the folder.  If that folder had been created
earlier during deliver, the create step by the MUA will fail because
it names the same folder.  But the important point right here is that
we do have a single folder name.  The MUA, after getting an error when
it asked for that folder to be created, could still find out if the
named folder exists or not be one of at least two method I believe
should be available to it:  (1) just try to open/access that folder
and see if that fails to succeeds.  (2) do a LIST (again) and see if
that folder name is now in there (was not in an earlier LIST before
the delivery happened that created it).  I believe method 1 would have
the least network traffic.


>> But if the IMAPD process itself can't or won't even try to access that
>> folder because it wasn't in the list when it started, then I see that
>> as a server side issue, or if the protocol doesn't provide any such
>> means to ask for a folder not previously seen, then I see that as a
>> protocol design issue.
>
> Wow, you really do know what you're talking about, don't you? *sigh*

I do not claim to know the IMAP protocol.  I can guess what makes
sense for it to have the capability to do.

What I DO know is what makes sense.  And one thing that makes sense is
that when user of an MUA tries to do a folder creation, when a folder
already exists because a successful email delivery created it a few
minutes ago, that the MUA should allow the user to access that folder
... even if the create operation done by the MUA through IMAP resulted
in an error result returned to the MUA.

In the case of Evolution, that did not happen.  It was necessary to
completely quit Evolution and start it again to access that folder.
Something is bad with that.  While I believe it is the fault of the
MUA, I was not certain since I do not know the IMAP protocol, or the
inner details of Dovecot.  I was just seeking a confirmation that it
is an MUA issue.


> In a nutshell: Failure to create a folder at delivery time is NOT an MUA
> issue. And whether or not the user will see new folders created
> successfully depends on (not) limiting to subscribed folders, and the
> subscription list stored on the server
>
> Basically, exactly what I wrote in my first reply. Mind reading that
> carefully again?

There was no failure at delivery time.  The failure happened when the
MUA asked for that folder to be created.

-- 
sHiFt HaPpEnS!