Amadeusz Żołnowski <aide...@aidecoe.name> writes: >> So... based on all the evidence so fare the culprit seems to be that >> something is moving mail files into your Spam folder on the client. >> If that rings any bells and solves the problem, great. If not, here >> is what we need to do to track it down further. > > I have followed you hints to track down the issue. All of these > messages are spam. What I suspect follows. > > All of these files have been placed to new/ subdir by maildrop and > during posthook (afew) have been stripped of any tags besides 'spam' > tag, in particular 'unread' tag has been removed, but files still remain > in new/ subdir. So... what had to happen is that during muchsync these > messages have been discovered as already read, so they don't belong to > new/ but must be moved to cur/. And this is what happened on client > side. During next muchsync these changes had to be pushed to server, > i.e. move from new/ to cur/.
Right. Muchsync checks to see if maildir.synchronize_flags is true on the client. If it is, then muchsync calls notmuch_message_tags_to_maildir_flags after setting the flags (which is the same as what would happen if you set the tags manually with the "notmuch tag" command). A maildir file in the new/ directory can't have any tags (except the implicit unread flag, which is indicated by the absence of "S" in the end of the filename). So the notmuch_message_tags_to_maildir_flags() function is renaming the file to the cur subdirectory, and then propagating this rename back to the server. The one thing I'm still unclear on is whether afew is running on the client of the server. If you are running it on the client, then this makes sense. If you are running it on the server, then somehow afew must not be respecting the maildir.synchronize_flags setting. Otherwise, the file should already be moved to the cur directory after having the unread tag stripped off on the server. I guess the other option is that your maildir.synchronize_flags false on the server and true on the client. > So if my assumptions are correct, actually there is no issue! I would > just have to adjust afew filtering to prevent this behaviour. Right. You could have afew preserve the unread flag on spam. Alternatively, you could just disable maildir.synchronize_flags on both the client and server. Finally, you could just accept the performance penalty, as one would hope that this is a one-time thing and that usually you don't have 5000 new spam messages every time you synchronize your mail. David _______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
