We have a postmaster filter to tag incoming spam mails that will probably look familiar to most Zammad admins:
- Conditions
- X-Spam-Flag: contains:
YES
- X-Spam-Flag: contains:
- Actions
- Tag: add:
spam
- State: closed
- Tag: add:
Combined with a scheduler that automatically deletes spam tickets after 30 days:
- Conditions
- Tags: contains one:
spam
- Created at: before (relative): 30: days
- Tags: contains one:
- Actions
- Action: delete
Unfortunately we recently learned the hard way that the following can happen:
- Customer sends a mail that is not considered spam
- Agent replies
- Repeat steps 1 & 2 several times
- Customer sends a mail that triggers the spam filter (false positive)
- The postmaster filter adds the
spam
tag to the ticket - The scheduler deletes the ticket (possible even on the very next run because the ticket might be far older than 30 days at this point)
That was obviously not our intention, and I suspect that we are not the only Zammad admins who have configured their system this way, and are therefore at risk for data loss.
IMO what’s needed here is a feature for the postmaster filters to properly differentiate between “new ticket is created” and “existing ticket is updated”, because as far as I can tell, it can’t do that currently. Then it would be possible to create a postmaster filter that will only tag newly created tickets as spam, and ignore any existing tickets.
Here’s a mockup I quickly hacked together:
Maybe there’s also an opportunity here to fix the confusing behavior that some actions apply every time, while some other actions only apply on ticket creation…?