I have read all of the various posts in the community forum pertaining to the observed error when clicking on the Incoming Message Rules –> WA_Blacklist_Check; however, I am still confused about the error cause and the expected timeline for this to be addressed.
I have read in a post last year that this error would be corrected in a “future update”. While I know this doesn’t specify an expected arrival for this correction, I did expect it would come within the year. However, I am still seeing this error on Release 10.6.23. Is this still something that will be corrected? If so, is there a timeline that can be shared with the community?
One of the posts in the Community Forum about this issue is quoted below:
”Please avoid editing any incoming message rules that are starting with WA_ prefix as they include some logic that is not supported by the current WA sieve editor.”
My reading of this implies that if I am seeing the error message “Error parsing the Sieve filters file. Nested expressions are not supported by the WebAdmin Sieve wizard.” I have edited something I shouldn’t have. If this is true, can anybody tell me how I reset this back to default so the error is no longer being seen?
Thank you all for any support.
Hello,
Please post some related logs so we could understand your specific problem.
The best way is to set Log Level to Protocol Communication for PROCESSING (via WebAdmin > Queue > Processing) and capture the logs for the message flow that generates the error you are referring to.
HTH,
Ioan
My apologies, I believe I didn’t explain what I am seeing very well.
When I access the WebAdmin –> Security & Filtering –> Incoming Message Rules –> Incoming Message Rules –> WA_Blacklist_Check –> Edit Pencil Icon, I am presented with a very odd background image in the browser window Main Frame, and if I scroll to the bottom of the frame, I see the following Error Message:
Error parsing the Sieve filters file.
Nested expressions are not supported by the WebAdmin Sieve wizard.
The logs don’t really show anything of value when receiving this error message (see below)
2025-11-24 16:43:55 +0000 08 axigen WEBADMIN:00001C95: Session 0xB5AF8432 associated with this connection
2025-11-24 16:43:55 +0000 08 axigen WEBADMIN:00001C95: <051fd3d7c33ca5973d4b5f5120acb876> GET /?_h=cb3810752319c7342e8b0b4b35e766b0&page=rlsve&action=edit&id=3&ruleKey=sieve HTTP/1.1 u=admin code=200 time=19
2025-11-24 16:44:01 +0000 08 axigen WEBADMIN:00001C93: Session 0xB5AF8432 associated with this connection
Hello,
All clear now - no need for logs.
If possible please share the wasieve-server.siev file (it should be present in the filters folders from the Axigen WORKING_DIR). If there are any sensible information you could send it to me via a PM.
BR,
Ioan
So I tried a little experiment. I downloaded Axigen and installed it in a fresh Ubuntu VM. I did not see any Filters listed in the WebAdmin –> Security & Filtering –> Incoming Message Rules –> Incoming Message Rules until I configured the section Attachment Filtering. Once I added an extension to filter the three “WA” filters appeared in the Incoming Message Filter section. Since this is a brand new install I assumed clicking on the WA_Blacklist_Check would work, however it shows me the exact same Error Message:
Error parsing the Sieve filters file.
Nested expressions are not supported by the WebAdmin Sieve wizard.
wasieve-server.sieve.zip (1.1 KB)
Hello,
Thank you for the simple replication scenario.
Indeed, the WA_Blacklist_Checkhas nested condition rules that are not supported by WebAdmin sieve editor.
On the other hand the admin is not supposed to edit from WebAdmin interface any sieve rule that is starting with the prefix WA_. Maybe the product team will choose to find them so it will not produce any similar questions but at this moment I hope you could just ignore those rules (or, if you really know what are you doing, to make your own changes in the dedicated file with any text editor + reload axigen service).
HTH,
Ioan
BR,
Ioan
So I have manually modified the file wasieve-server.sieve to remove the nested entries in the filters. However I would strongly suggest the Devs FIX this issue. This is a Day 0 BUG and should have been addressed long before now.
The applications own logic is building the wasieve-server.sieve filters completely incorrectly when adding File Extension filters using the Web Admin Attachment Filtering section of the GUI the Web Admin (and underlying logic) is building the filter with Nested “allof” and “anyof” entries that the Filter Engine can’t parse or understand. How is supposed to work? No way Axigen is actually filtering out file extensions that are defined to be rejected in the GUI.
As it stands right now I don’t see how Axigen can possibly have active file extension filtering since using the GUI builds a NESTED sieve filter that is rejected by the filtering Engine. And when I manually break out all of the file extensions in to their own Filter IDs so they are no longer nested the GUI will not show the resulting filters, and I have to assume the filter engine is not going accept the filters written this way. Either the Filter Engine needs to be corrected to accept NESTED logic in a Filter entry or the GUI needs to be updated to build and display the filters as individual entries so the Engine doesn’t reject them. Either way it’s a Day 0 BUG and should have been identified and corrected LONG before now.
This is extremely disappointing.
Actually I stand corrected, as I performed a test by sending a file that is blocked by the file extension filters and it does get blocked.
However, the GUI is still messed up since I have removed the nested statements in the sieve filter, the GUI is no longer parsing the filter and showing what file extensions are designated to be blocked. So again either you can manually build the file extension filter by editing the wasieve-server.sieve file or you can use the GUI and deal with having the WA_Blacklist_Check not displayed correctly in the GUI. I suppose since this WA_Blacklist_Check isn’t actually supposed to be edited in the GUI it doesn’t matter, but it’s still poor development to know this bug exists and to not have fixed it in over a year of it being reported. Why would you ignore a GUI bug like this that seems relatively easy to fix?
If the WA_ filters are supposed to be off limits, why show them at all in GUI, just add a rule to skip showing any filter that starts with WA_. This too would be a simple work around it seems.