any authenticated user can release emails if quarantined?

[spaghett-i]

RHEL mailwatch 1.2

any user can release a message, and this permanently releases all future messages with the same to/from address and subject. I tried looking through documentation for how to disable this as well as fix the already released messages, but I don't know where they are stored.

on viewmail.php in the Actions portion where the "Release this message | Delete this message" buttons are.

I plan on removing the buttons from viewmail.php, just not sure how to reset whatever damage has been done. Is there a list/rule for released messages through this method?

[shawniverson]

Releasing a message releases just that message, so I'm not sure what you mean that it releases future messages. There is no list or rule that is populated from this action, unless you have some kind of auto allowlisting going on in the background. The most that happens is the message is tagged in the database as released.

If MailWatch is set up with proper access control, users can only see and release their own messages.

[spaghett-i]

thanks for the reply, I am still trying to dig into how they are getting through. Was just scrambling initially because it's a big issue for us if users can allow emails out. Before I delete the buttons out of viewmail.php is there a more suitable way? I will need to follow up with user to see if they in fact are not manually clicking release but I am seeing "Message released from quarantine" emails and there isn't an email before it with a "released" status. I see them hit my postfix header_check and they are held. Then they are picked up from quarantine and forwarded to him like this: 0FE5526086D: hold: header Subject: Message released from quarantine from localhost[127.0.0.1]; @.***> I am using rules/header_checks but I don't have anything picking stuff up out of quarantine like these are. I don't think I modified the base files that much. I don't really use spamassassin or have it configured. I primarily rely on header_checks and spam.whitelist.rules.

On Tue, Feb 27, 2024 at 5:07 PM Shawn Iverson @.***> wrote:

Releasing a message releases just that message, so I'm not sure what you mean that it releases future messages. There is no list or rule that is populated from this action, unless you have some kind of auto allowlisting going on in the background. The most that happens is the message is tagged in the database as released.

If MailWatch is set up with proper access control, users can only see and release their own messages.

— Reply to this email directly, view it on GitHub https://github.com/mailwatch/MailWatch/issues/1298#issuecomment-1967876171, or unsubscribe https://github.com/notifications/unsubscribe-auth/BGQMJ3EUPGFAZOMRGBGT2DLYVZRL7AVCNFSM6AAAAABD47CWROVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRXHA3TMMJXGE . You are receiving this because you authored the thread.Message ID: @.***>

[Skywalker-11]

Can you check your web servers access log if the mailwatch interfaces was accessed around the time that the mail was released? You can also check the audit log or if not done yet enable it in the conf file to check if the relase was triggered by a user define('AUDIT', true);

[Skywalker-11]

Also check if you have set define('AUTO_RELEASE', false); in the conf

[spaghett-i]

Can you check your web servers access log if the mailwatch interfaces was accessed around the time that the mail was released? You can also check the audit log or if not done yet enable it in the conf file to check if the relase was triggered by a user define('AUDIT', true);

both audit and auto_release are set to false. If AUDIT is true where is the log generated? A bit embarrassing, but at around the same time the customer released the message they also modified their subject, and the new subject started matching a header_check so they weren't actually able to release emails. whew.. I'm going to mark this as closed. I appreciate the help.