Currently Tb excludes the junk and trash special folders from the list of recent move/copy targets that populates the "Copy To" and "Move To" menus (both right click and Message main menu). This seems to be a leftover from an earlier workaround for the bug where automatic message actions would pollute that MRU list with the folders they modified, most commonly the junk/trash folders. Since that bug has apparently been long since fixed, the exclusion no longer makes sense and just gets in the way. If the previous paragraph is the correct root cause assumption, and the code is still as in the patch that fixed #370324 then the most likely fix is probably simply changing the code in nsMsgDBFolder::UpdateTimestamps() to not check the junk/trash flags and instead move the MRU update inside the "AllowUndo" (or its more exact successor) conditional. Note that the URL goes to the mentioned old patch that apparently closed #370324 and moved (but not introduced) the check for junk/trash special from two other places to UpdateTimestamps(). Steps to reproduce: 1. Manually move a message to the junk IMAP special folder 2. Manually move a different message to some other IMAP (non-special) folder 3. Right click on a third message intending to move it to the junk IMAP special folder 4. On the right click menu, navigate to "Move To -> Recent" looking for the recently targeted junk IMAP special folder. Actual result: At step 4, the junk IMAP special folder is not on the recent list, forcing a slow manual navigation in order to move the third message there. Expected result: The junk IMAP special folder should have been in the recent list, since it was the second-most-recently used manual move/copy target (from step 1 of the reproduction). P.S. Observed using the shipping 45.6.0 regular build on Windows 8.1, running against various IMAP accounts.

(Please use syntax of bug xxx so the get linked, for example bug 370324) Indeed, they are intentionally excluded. IIRC, your request would hurt users that don't want to see those folders in Recent, and they would when a message is junked or deleted by a mechanism other than drag and drop. (not just filters)

Point is that when *not* allowing Tb to automatically move/delete suspected spam messages, manually moving messages to the junk mailbox is a very common user action, where users are hurt by the current behavior of omitting the junk folder from the MRU list. Another point is that the extra condition "if (AllowUndo)" added in the referenced patch from 2011 is supposed (according to comments in #370324 and in the patch itself) to already exclude cases where a message is moved, junked, deleted etc. by any of the automated mechanisms. However the phrasing "proxy for" in that patch hints at this being a potentially imperfect condition for determining if this is an explicit move or copy operation by the user, rather than an implicit one occurring as part of something else (such as the user "deleting" a message). Finding an even more precise condition to filter out move/copy operations not explicitly done by the user requires more knowledge of Tb internals that I have. Also note that Drag and Drop to one of the special folders is not the only user action that *should* add something to that MRU list or update its recentness in the list. The most important other such action would be to use either of the menu items mentioned in Comment #0 to explicitly move/copy a message there. P.S. The component and branch that you moved this bug to were not available for selection in the Bugzilla web interface available to me as an outside user, not even as searchable locations in Advanced bug search. I thus presumed that "45 branch" was the only way to indicate that a bug was in the shipping 45.x.x release and that "Mail Window Front End" was the current component for that code.