Sieve won't move emails to folders, only copy them

Hi all,
Prerequisite information:

• Ubuntu 20.04 LTS
• ISPConfig 3.2.9 installed with automated installer
  
• Virtual machine (VMware ESX), 4 CPU, 64 GB RAM, (2) disks: 60 GB / for OS (19% used), and 500 GB /var for mailboxes, websites, etc (13% used).
• OS and ISPConfig are complete up to date on patches

I'm having an issue where my sieve rules (stored in /var/vmail/mydomain.com/myuser/.ispconfig-before.sieve and also .ispconfig.sieve) are running and the rule is filing the emails where I want them to be filed, but it won't delete the email from the inbox. It's like fileinto is copying the email instead of moving it, and even if I add discard; into the block, it still does not delete the email. Which feels like sieve/dovecot/whatever does not have the rights to delete email files from /var/vmail/mydomain.com/myuser/Maildir/cur.

Checking permissions on these folders, It looks like vmail:vmail is the owner:group, and 0600 is the permission set used.

After doing some research, I SSH'ed in and sudo'ed over to the root account, went to /var/vmail/mydomain.com/myuser, and ran 'sievec .ispconfig-before.sieve'. It found a few errors, and I fixed them in the ISPConfig GUI. After ISPConfig ran it's once a minute maintenance script, I went back and re-ran sievec on the file. It came back with no errors and it generated a .ispconfig-before.svbin file consistent with the time and date. These files have vmail:vmail as the group : owner and 644 permissions on them. I then sent a test email and there was no change in behavior. The message I sent ends up in the folder I've designated, but it also continues to exist in the inbox.

When I discovered sieve and the power it has, I was excited. After banging my head against a wall on this for a week or so, I'm less so. I've even got a utility that I downloaded onto my PC that makes sure I write syntax compliant sieve rules. And I now know about running sievec on the file and getting it's take on it too. But I've run out of things to check. I'm wondering if this is something others have run into?

Oh, FYI - I've both written rules myself and had the ISPConfig GUI help me (the Mail Filter tab). The result is the same, though the syntax differs a bit between them.

The present rule:
if allof(envelope "From" "[email protected]") {
fileinto :create "INBOX.Backups.ADomain";
discard;
}

I've checked logs in /var/log/dovecot.conf. I don't see anything of significance there. I'm including the logs below. I'm also dumping out a copy of doveconf. Maybe someone sees something there I missed?

Thanks, in advance!

Attached:

• a dump of doveconf (note: ALL settings here either come from setting things in the ISPConfig admin interface, or from conf.d/99-ispconfig-custom-config.conf)
• a sample of /var/log/dovecot.log (Filtered for my email account only. There are about 50 email accounts on here, and I don't want to expose everyone's stuff)

 

No, but let me try it real quick!

 

OK, so adding stop; didn't make a difference. But I decided to start testing with some other email messages that had different from fields, and the answer really comes down to "sieve seems to be finicky." For instance, if I view the source of one of these emails, the From: field only states [[email protected]] - no brackets, no "pretty name", nothing specific. It should be a direct match, as I'm even matching the case of the email address, even though sieve is supposed to ignore the case by default when making a match. And yet it does not match. Then...

Going to the ISPConfig rule builder and building out a rule for this, it uses a RegEx to do the match, something like "^ALocation@ADomain\.com$" when I use the IS statement for comparison in the builder. And again, this should be a perfect match. And yet, sieve doesn't see it that way.

So finally, I experiment, adjusting the rule to be a regex statement from ".*ALocation@ADomain\\.com" and it works! But why? And why was it not deleting the emails from the inbox the first times around?

Testing with a different email address, I get emails from Auvik, a network monitoring service. Their From: field in the header of the message looks like [From: Auvik System <[email protected]>]. So, knowing what I now know, I build a rule that uses Contains: instead of Is: and specify "[email protected]", which ISPConfig helpfully converts to [".*noreply@auvik\\.com"], and that rule MOVES all the Auvik emails (which there are a lot of in my Inbox) to a subfolder I've created called "NetMonAlerts" the first time through. Again, the mystery is, why does this rule work great and the one before it didn't?

So, in the end, I love what the sieve-mailfilter people are doing, but it's a bit too technical still for me to have even power users doing. Which basically means, I'm going to either end up writing every rule for them myself, or I'm going to be troubleshooting why their rules don't work. Which by no means is anyone at ISPConfig's fault. It's just annoying is all.

FYI, the editor I've run a bunch of things through to check syntax (but not save their file to the server) is ManageSieve v0.6.1 - I find the drag and drop functionality of the whole thing to be pretty easy to work with. And I can take existing Sieve scripts, paste them into the text editor, and switch to the GUI editor to see exactly what they are doing. So, just in case someone else needs this information.

Thank you for your assistance, Til! Even if it was just to hear me out while I wasted hours figuring it all out.

Oh... because I know I'm going to get this response from someone... YES, I could (and have) used Outlook Filtering Rules or Thunderbird Filtering Rules to do all of what I'm describing above. But that means I have to leave that software up and running on a PC somewhere all the time. And the goal here is for the rules to be server-side, so I can have my laptop in a backpack while I'm traveling and my phone isn't getting lit up with emails that I don't need to be distracted by while I'm away from the computer. This is all about being able to build rules on a server side and forget about it.
Paul