Hello everyone,
I am running into a strange issue with MTA and Threat Extraction on our gateway (running R81.20).
The Scenario: We have MTA configured with Threat Extraction and Threat Emulation. A user received an email containing a password-protected PDF. As expected (and configured by our policy), Threat Extraction blocked the original attachment since it couldn't parse it, and delivered a cleaned/notification email to the user.
The Issue: Because this is a legitimate business file, the user clicked the UserCheck link to request the original attachment.
The user reaches the "Company Policy" page, provides a justification, checks the "I confirm that the files are coming from a trusted source" box, and clicks Confirm (Image 1).

The portal then loads an "Action Succeeded" page, but the download link for the original file is crossed out with the message: "(blocked according to company policy)" (Image 2).

Troubleshooting done so far: I connected via CLI to check if the original file is even available for download. I checked the MTA quarantine directory (/var/log/jail/tmp/scrub), but the file is not there.
Has anyone encountered this specific behavior where the UserCheck portal confirms the action but immediately enforces a secondary policy block?
Could this be a conflict where Threat Emulation (TE) strict policy is overriding the Threat Extraction (TEX) user release?
Why wouldn't the original file be stored in the scrub/quarantine directory? Is there another path for MTA retained files I should check?
Any pointers on which specific logs (emaild.elg, scrubd.elg, etc.) to debug for this UserCheck release workflow would be greatly appreciated.
