Problem:
Spamreporter forces you to authenticate via a login (example below)
- or -
It seems to be functioning normally but when you trust or block someone, the user level trust and blocklist on the proofpoint side doesn't get updated.
Example authentication request:
Note that this should never happen - the modern plugin will autonegotiate with the spamreporter server on the backend via a handshake email. If the above happens, then it means the existing token is no longer valid and a renegotiation needs to be forced.
Applies to:
Spamreporter stand-alone version. It's the version of the plugin that works with Microsoft Exchange On-Prem. Does NOT affect SRC365 (the version of the SpamReporter pushed out for Office365 users).
Cause:
Several security updates on the proofpoint side and microsoft side have forced us to make changes to the spamreporter server on the back end and the only way to fix it is to force a new authentication handshake between the client (spamreporter add-in) and the backend server.
Fix:
Unfortunately, there's no way for us to trigger a new handshake remotely.
To trigger it, you will need to go into each user folder on their workstation and delete or rename the Vircom.dQ.Client.dll.config file in the folder:
c:\users\<username>\appdata\local\vircom\directquarantine folder.
This will re-initiate a new handshake with the spamreporter server and would address invalid padding issues.
Our suggestion would make to do a simple login script that would be called on the next workstation boot up that does a one shot delete of the config file
Renegotiation/Handshaking will happen automatically during outlook startup.