Admins say on this idea { Link } that they need the possibility to move mails from one mail.box to an other by hand.

Why not move by a servertask?

I don't think that there is a need for a server task. For the number of times that this happens (rather low, usually), the manual method works just fine.

It works for you, Gregg.
If you have tousends of users who send mails, it doesn't work well.
Sometime we wait minutes before the mail.box opens.

My main concern with this idea is the possibility of problems caused by two tasks trying to process the same messages at once. As the task is running on another server, it can't know what the router on the first server is doing. This means it may move mails that are actually being handled - which isn't good.

The second is that some AV tasks and compliance archiving systems need access before the router. Usually this is done by marking mails as dead, and hopefully such a server task would ignore dead mails. But basically again we have the possibility that you could interfere with processing in progress on the remote server.
At best, you confuse such systems. At worst, you risk causing corruption or data loss.

This means that such a task should not be done remotely, but should be performed on the server that has the problem. As such, I'm already inclined to vote the suggestion down.

Outside of those considerations, I'm also wondering why you'd need this. For example, where is the delay?

If the delay is on the server due to large attachments that are being agressively AV-checked, or some similar task, then I suppose this could have merit.

But if it's just mails that are waiting for redelivery because the next hop (usually SMTP, occasionally NRPC) is not available - well, this doesn't seem to make much difference.
If you know the next hop is back up, use the "route" command. And if it's still down, then moving the messages to another server does not really speed up delivery, it just gives you a large mail queue on two servers rather than one.

A better method than a mail task would be a "tell router nexthop" command which forces the router to send all mails, regardless of destination, to a specified server or SMTP address - effectively putting in place a temporary relay host. But as this config would probably be lost if the server rebooted or crashed, I'd agree with Gregg that the traditional way - modifying the connections or configuration document in the NAB - is better.

Of course, that's for situations where you want to move the mail flow to another server for a short while. For situations where you're trying to clear a backlog, the traditional method of copying and pasting is probably also better.

Personally, I usually stop the router and take the mail.box file(s) elsewhere, then let the router create new ones. That way I can integrity check them, and paste mails back in with more control - which can help to identify messages that are causing issues. A movemail command wouldn't do that, it'd just risk putting the same problem on two servers.

Overall, I don't see how this would make my life easier. Regardless of the root cause of a large mail queue, this doesn't seem to help.

@3, if you have thousands of messages -- excluding spam -- then perhaps you lack the proper quantity of mail.box files. Try setting it to 3 and reboot the server.

@2 is correct as well, because sometime the backlog is due to a corrupt message. The manual method lets you isolate it without causing further delays or outages. There is no guarantee in this scenario that a server task would be any better at removing a corrupted message block, as the message is damaged.