Recently I've implemented a solution to prevent executable within archived files. This also is looking for executable attachments.
It was not something I wrote personally, but was able to get working on my server.
The issue I'm having now though is some users are reporting false positives when sending from Outlook. The message they are getting indicates it's with the first portion of the ACL looking for forbidden attachments:
WINBIN = exe|com|js|pif|scr|bat|flv|reg|btm|chm|cmd|cpl|dat|dll|hta|jse|jsp|lnk|msi|prf|sys|vb|vbe|vbs
COMPREXT = zip|rar|7z|arj|bz2|gz|uue|xz|z
BINFORBIDDEN = Windows-executable attachments forbidden
deny message = BINFORBIDDEN
log_message = forbidden attachment: filename=$mime_filename, \
I'm unable to find the cause of this, though I've found that removing the way Outlook has cached the email and re-entering it fixes the problem.
For example, Outlook might have the email saved as "'Person Name' <[email protected]>;" which would cause a fail, and yet emailing "[email protected];" would not.
That being said, I'd like to know what is causing this. At first I suspected it had to do with characters in the email address, especially the presence of single quotes, but alas, the second user to report this issue doesn't have any quotation marks in the address.
I could not reproduce these false positives unless I copied and pasted the address from their computer to my own (via remote session). If I tried to hand type the email address, matching each character, it would be delivered just fine.
Crazy right, any idea why it's seeing some email addresses as harmful attachments?
It was not something I wrote personally, but was able to get working on my server.
The issue I'm having now though is some users are reporting false positives when sending from Outlook. The message they are getting indicates it's with the first portion of the ACL looking for forbidden attachments:
WINBIN = exe|com|js|pif|scr|bat|flv|reg|btm|chm|cmd|cpl|dat|dll|hta|jse|jsp|lnk|msi|prf|sys|vb|vbe|vbs
COMPREXT = zip|rar|7z|arj|bz2|gz|uue|xz|z
BINFORBIDDEN = Windows-executable attachments forbidden
deny message = BINFORBIDDEN
log_message = forbidden attachment: filename=$mime_filename, \
content-type=$mime_content_type, recipients=$recipients
condition = ${if or{\{match{$mime_content_type}{(?i)executable}}\
{match{$mime_filename}{\N(?i)\.(WINBIN)$\N}}\
}}{match{$mime_filename}{\N(?i)\.(WINBIN)$\N}}\
I'm unable to find the cause of this, though I've found that removing the way Outlook has cached the email and re-entering it fixes the problem.
For example, Outlook might have the email saved as "'Person Name' <[email protected]>;" which would cause a fail, and yet emailing "[email protected];" would not.
That being said, I'd like to know what is causing this. At first I suspected it had to do with characters in the email address, especially the presence of single quotes, but alas, the second user to report this issue doesn't have any quotation marks in the address.
I could not reproduce these false positives unless I copied and pasted the address from their computer to my own (via remote session). If I tried to hand type the email address, matching each character, it would be delivered just fine.
Crazy right, any idea why it's seeing some email addresses as harmful attachments?
