<div class="markdown">
<p dir="auto">On 11 Jan 2014, at 23:20, Bill Cole wrote:</p>

<blockquote>
<p dir="auto">The way to do that with a correctly-behaving IMAP server is to create a new folder, copy all of the existing messages into it, and delete them from the original folder. This seems to be what MM does and it is a less risky and more universally workable strategy, but in principle it should be possible to do a real tree rearrangement with one RENAME command instead. I am interested in <em>why</em> Benny chose not to use RENAME.</p>
</blockquote>

<p dir="auto">That’s a good question. I had completely forgotten this part of the IMAP RFC. I cannot recall any other reason for not using it than the current behavior means that I can do the same thing no matter what action the user has taken (renaming or dragging a mailbox to a different location or even a different account — it’s all a variation of moving messages).</p>

<p dir="auto">With respect to performance. For MailMate it would not be more efficient to use RENAME. It would just be a different code-path. Some servers though probably handle RENAME much more efficiently — and for some servers it would also mean that quota limits would not come into play.</p>

<p dir="auto">In any case, the biggest performance problem with renaming IMAP mailboxes is not solved by RENAME. It’s only the email client doing the renaming that can handle it efficiently. All other (offline) email clients are, at least in theory, going to clear their caches and then refetch all messages in renamed mailboxes.</p>

<p dir="auto">@Kee: Yes, MailMate should be smarter about renaming (and moving) a parent mailbox.</p>

<p dir="auto">I’ll put IMAP RENAME on the list of potential performance improvements.</p>

<p dir="auto">-- <br>
Benny</p>

</div>