Imapsync: synchronize the trash to a new server or not

I wanted to post an update to this just migrated my primary mailbox from one NS install to another. Everything was transferred except those in the Trash folder. Is this expected?

1 Like

yes this is expected

however you could patch the systemd service if really you need it

Maybe a very niche case, but would it be very problematic to have a check box that would enable a feature like this on a per user basis?

1 Like

Hello @nrauso do you think it could valuable to synchronize what it is in the Trash, in other word does worth it

Not sure it could be a good idea :thinking:
Trash bin should contain unwanted mails, among them could be malicious contents…

1 Like

I tend to agree with @nrauso. It’s called trash to get rid of the mails. Although I have seen people using it as archive. (yeah I did convince them to use something else as archive)
If you desperately need to have the mails in Trash to send over, just create a new directory and move the mails there. Otherwise: trash is trash and those mails should be deleted permanently anyway. I strongly favor to empty trash every time you close the client.

You have met my father ?


I tend to think the opposite way.

Personally I don’t really see why we wouldn’t transfer the trash wether it’s useful or not from the sysadmin point of view. Trash is there for a reason : being able for the user to get things back if needed.

Why would the action fo a mailbox transfer (which must normally be strictly transparent to the user) compromise that feature ? From the user perspective that would be incomprehensible.

—> I believe that that mailbox should be transferred, as a all other folders, no need for a setting.




As in (most) normal office: Throw anything into the trash can, it’s still there later…

Tomorrow morning, the trash can is empty.

This is very often the case in “cleaned” offices.

This is also what most people are used to, and should constitute the “norm”.

Ever tried putting your savings in the trash can outside and see how long it’s still there? :slight_smile:

My 2 cents

My point is that in the computer world the trash is never emptied until the user decide it. He is therefore expecting that the trash will follow him during the migration.

There is more work, potential problems and discussion involved in deleting it than keeping it :blush:



You’re not completely “unright”, but:

As I mentionned, I’ve seen a lot of companies, where trash, especially in mail, is emptied as soon as the user logs out.
And a lot mandate log off at night!

My 2 cents

In that case transferring the Trash bin will simply be faster, good for us :blush:

1 Like

This simply isn’t correct. The Trash on a Mac, the Recycle Bin on Windows, and (depending on the mail client) the trash folder on email, all empty automatically under certain circumstances.

Or some of my customers? :thinking:


Theoretically. In practise it’s much less the case. And anyway, the user knows and expect that but doesn’t know nor expect that us stubborn sysadmins will suddenly decide that for one time the rule will be changed.

What the user should know and expect is that the trash (in any of those cases) is a transient storage place, that items placed there inadvertently should be removed as soon as possible, and not to expect items placed there to stay there for any significant period of time. If not syncing the trash folder causes them problems, it’s because they were misusing the trash folder.

Why would you expect such a transfer to be transparent? If you’re moving from one host to another, there are almost certainly going to be differences in account settings–those will not be transparent. The address will probably change–that will not be transparent. This isn’t going to be something that’s going to happen behind the scenes over the weekend, and staff will log in on Monday none the wiser. This isn’t a system backup/restore, which should be transparent.

Now, with that said, I don’t have a particularly strong opinion whether to sync it or not. On the one hand, I don’t see why we should go out of our way to support people who are misusing this feature. On the other hand, it seems like it should be relatively trivial to include it in the sync.

You’re doing a bright demonstration of the exact contrary of my view. Things HAVE to be transparent, and the user should NOT suffer from a technical issue like a migration from one server to another (that’s the case which is covered here).

Anyway, I think everyone understood my point. I’d like that any sysadmin thinks the user way, not his own way.

I’ll try to put in the simplest way possible.
If i am migrating from a old mail server to a new one I personally won’t sync the trash folder. But i will surely use the setting for all of my users, because they simply don’t want to know, understand, have compliant habits with the design of things.
I suggest to enable as default sync of trash and spam (separated setting), also not into an advanced submenu.
I also suggest to add a comprehensive description for what both settings do.

Usefulness of spam is due to train spam filter, if necessary.
Usefulness of thrash is for… messy user, and as insurance policy for not that transparent customers. They might happen.

As some says, my two cents about that.

1 Like

@stephdl prepared a great PR to implement the Trash folder exclusion. He can merge it as-is or we can see if an alternative UI design can make the final feature more flexible.

As I’d like to consider a more generic approach (either for now or for the future) I report here my latest comment for further discussion:

[…] I’m thinking about the “Public” and “Shared” namespaces prefixes: as we are synchronizing with a remote IMAP server we can’t make assumptions on its folder naming scheme.

“Synchronize the Trash” could become a switch between the “default exclusion” pattern and a custom one (pre-filled with the default pattern and modifiable).

Dynamic exclusion of Trash folder by stephdl · Pull Request #237 · NethServer/nethserver-mail · GitHub

1 Like

Let’s go with the merge, we can improve further the exclusion list in the future, if it will be come a common request.

1 Like