[Dovecot] Is this really a user agent issue?

[Karsten Bräckelmann]

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.

> 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.

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.

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


> 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.

> 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.

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.


> 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.

"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...

> 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*


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?


-- 
char *t="\10pse\0r\0dtu\0. at ghno\x4e\xc8\x79\xf4\xab\x51\x8a\x10\xf4\xf4\xc4";
main(){ char h,m=h=*t++,*x=t+2*h,c,i,l=*x,s=0; for (i=0;i<l;i++){ i%8? c<<=1:
(c=*++x); c&128 && (s+=h); if (!(h>>=1)||!t[s+h]){ putchar(t[s]);h=m;s=0; }}}