Spammers getting by Content-Filtering rules
Problem reported by Jay Altemoos - 5/8/2018 at 2:36 PM
Good day all. Today one of my co-wrokers brought to my attention that they got a email with a ZIP attachment in their Junk E-Mail folder when we have a rule set up to Bounce any emails with ZIP attachments except users that we list are allowed to get them. I believe I found out why and I tested my theory by sending an email from my Gmail account with a test email with a ZIP attachment to ensure the rule is working.
Here's how my rule is set up:
Domain -> Filtering -> Content Filtering -> (Rule to Bounce emails with ZIP attachments)
So the rule is as follows:
To specific addresses, has specific attachment Enable wildcards in search strings ( * and ? ), (Does not Match) (We have people that need to get ZIP attachments), Specific extension (one per line) (Matches) *.zip
Now the rule so far has been working to my knowledge and in my testing I get a rejection back that my email was rejected: Reason: Recipient spam or content filter rejected the message
So yes my rule works, but here's what's odd and what I noticed for the example email that got sent to a user's Junk E-mail folder and was not on the allowed list:
I just copied the header content type section that pertains to the attachment in both cases
Header for the spammer email that got sent to Junk E-Mail with attachment intact:
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename= "DOC2146617823.zip"
Header form my test email (Gmail) that got rejected:
Content-Type: application/x-zip-compressed; name="test_doc.zip"
Content-Disposition: attachment; filename="test_doc.zip"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_jgy5x6to0
What I noticed here was the difference in headers was this line: Content-Type: application/octet-stream vs Content-Type: application/x-zip-compressed; name="test_doc.zip"
Could the application/octect-stream be the reason why the ZIP attachment got through? It seems to me that if this is the case, then spammers could exploit a bypass to get by a rule. This rule should have trapped this spam appropriately and it did not. In fact in my log file SM catalogs the email as spam and just delivers it to the users Junk E-Mail. Whereas my Gmail email got bounced like it should have, but the Content-Type on my test email specifically lists the x-zip-compressed. So any idea what the issue might be? Should I add to seach for the words ZIP in the header information as well?

Reply to Thread