Marking as rejected, for reasons discussed previously.

When/if we develop a way to cleanly add more elements to the 
smartmobile UI, this (and other features) may be added.

I respectfully disagree.  Maybe I have butterfingers but I think I 
have accidentally touched the wrong segment of a tiny display on a 
smartphone plenty of times.  Maybe I am in the minority or have extra 
large fingers!  :-)
Agreed.  But I think if a delete key is offered, it is somewhat 
expected to offer an undelete.  No need for extra buttons or anything 
since you can hit delete on a previously deleted message to undelete.   
If I hit 'Reply ' on a message and go into message composition screen 
for the reply, I am given a 'Cancel' button to quit in case I made a 
mistake.  Just asking the same for Delete!

Thanks.

I dare to say that most installations support users who want to access 
the same backend using multiple UIs.  Maybe I am wrong but I think 
most installations have normal GUI clients that want mobile access too.

Having a trash mailbox may be an answer but we normally don't define a 
trash folder on the server.  Normal IMAP style message mark for 
deletion and then purge deleted works.

If you require a Trash mailbox to fully support what I call undelete 
in the mobile view, then why not only provide a 'delete' button in 
mobile view IF the user has a Trash mailbox and has selected moving 
deleted messages to trash in their preferences.  This would solve the 
problem, all be it not what I would want.

I disagree with this logic.  From a practical standpoint, people 
simply DON'T delete messages accidentally.  And if this is truly a 
problem, then use a Trash mailbox.  Problem solved (the correct way).

Again - this is a fundamental misunderstanding of what the smartmobile 
view is.  It is NOT intended to be a complete mail application.  It is 
meant to quickly view messages and do extremely basic actions.   
Anything more is going beyond the scope of what is available given the 
UI.

As mentioned, the paradigm of leaving messages in the current mailbox 
simply does not work when you have a minimal UI.  And that's not just 
me talking - while we were coming up with the new MOVE IMAP extension, 
*nobody* does it this way anymore.  Everybody uses a Trash mailbox 
these days, precisely because the nature of accessing mailboxes has 
changed and marking in place doesn't work once you move beyond the 
idea of a connected mailbox that always has access to the full list of 
messages in a mailbox.

I apologize.  I may be mixing various threads/tickets.  But at least 
one person in the past has said Undelete should appear because it is 
in at least one other view.  I was just trying to point out that is 
entirely irrelevant as to whether Undelete should appear in a 
different view.
There are obviously drawbacks for not allowing the Undelete button.   
This is the primary one.  But the other factors I previously listed 
outweigh this drawback, IMHO.

The bigger issue is that the idea of keeping deleted messages in the 
mailbox is, from an implementation perspective, the absolute worst way 
to handle deleting messages.  From an implementation perspective, the 
only paradigm that makes sense is a Trash mailbox.  In other words, on 
a server that only offered a smartmobile instance, nobody would ever 
offer anything but delete w/Trash.

The issue comes when you are trying to support multiple UIs using the 
same backend.  Deleting in place is a valid use-case when you have a 
screen with sufficient information density to not affect work flow.

Our replies crossed. I wasn't responding to you, but to Michael :)

I think you misunderstood what I was saying.  I didn't say remove the 
delete/undelte capability from any other interface.  I said if you 
allow for delete in the smartmobile interface, then it would make 
sense (for reasons I stated) to allow for undelete.  If that is not 
acceptable, then I said why not just remove the delete capability from 
the smartmobile (only) interface all together.

Completely disagree. By doing this you prevent users from accessing 
any message they may have accidentally deleted - regardless of which 
interface this was done in. I understand the UI argument you are 
making, but forcing a user to logout and attempt to login to a 
different view on their mobile device if an email is accidentally 
deleted is absurd.

Thanks for your reply.  First, let me say that I never said the above 
quote.  I would never assume that if a function exists in one view, it 
should also exists in another.

That said, I completely agree with your description and if 
delete/reply/move are base actions and you do support them but 
undelete is not, then my only comment and reason for asking my initial 
question is this:

If you do allow for delete and provide a button for it, the I see the 
case where a user will accidentally hit the delete button, delete the 
message and have no way to undo what they did.  This may be fine, but 
in my view is undesirable.  I would much rather have NO delete button 
than have the button and not be able to undo an accidental delete.   
Particularly with smaller devices where hitting the wrong button may 
be more common.

I agree that there is limited room for more and more buttons.  That's 
why I suggested hitting the delete button on a deleted message to 
undelete it.  Or, add it to the 'More' list.

As it is now, if a mobile user accidentally deletes a message, then 
they have to remember to login using another interface and undelete 
those messages that they may have accidentally deleted.  Is this ok?   
I will leave it up to you to decide but just wanted to point out the 
issues from a user and a support perspective.  Thanks again.

Undelete is intentionally left out of smartmobile.  And I don't see 
any reason otherwise.

First - you make the common mistake of saying "this feature exists in 
a different view of IMP; it should/must appear here."  There could not 
be further from the truth.  While true that we can't have any 
particular ACTION behave differently among the views (i.e. clicking 
Delete in smartmobile must behave the same as clicking Delete in 
basic), this has nothing to do with which FEATURES we allow.

In the smartmobile case, it makes ZERO sense to show deleted messages 
in a mailbox.  You are given limited screen real estate and network 
connectivity - it only makes sense to show messages to users that they 
think are "interesting".  By previously marking a message as deleted, 
they have explicitly made the statement that the message is no longer 
"interesting" to them.

In other words: "Undelete" is not a base action, like 
delete/move/reply.  it is instead an action that helps manage a 
mailbox.  Smartmobile is not designed UI-wise to manage a mailbox.  It 
is designed to allow quick access to messages and the ability to do a 
few of the basic things needed to quickly handle the message data.

And I shudder to think of the cascading effect of adding this.  Once 
you allow Undelete, you require messages to be visible in the mailbox 
view - undesirable, as mentioned above.  Some some people will want 
the ability to turn this off dynamically, so now you have to add a 
button to allow toggling of hiding messages.  And then people are 
going to want the ability to expunge the messages, since they can now 
see them, so you need to add an Expunge method (and the modal warnings 
required to prevent accidental clicking).  There is really no more 
room for 3-4 more actions in the current layout as it is.

These might be allowable in a "tablet" view, but never a "smartmobile" 
view.  Since we only have one view that encapsulates both, we have to 
tailor the UI to the latter.

Sorry, the ticketing system said IMP for mobile devices so I assumed 
that would be the right queue.  IMP I guess would be the right queue 
and I should have mentioned using the mobile interface.  Thanks for 
the clarification.

MIMP is not the smartphone interface of IMP, it's a completely 
different, depracated and unsupported application.

Looks like someone moved this ticket to IMP.  I did open in MIMP 
queue.  Thanks.

Very sorry, I thought I selected the MIMP queue but apparently not.   
Yes, this is in Smartmobile mode.

You didn't mention that you are talking about the smartphone interface.

Not using a trash folder.  That setting is not selected in the user 
preference and there is no trash mailbox.  This behavior is only in 
the Smartmobile view.  Are you saying that you can undelete messages 
in smartmobile?

Don't use a trash folder.

It would be nice to allow for either an Undelete message option for 
have the existing delete function act as an undelete when you delete 
an already deleted message.

Thanks.
Aria