On Thu, 22 Feb 2018, RW wrote:

On Thu, 22 Feb 2018 15:54:45 +0100
saqariden wrote:

Hello guys,

I have the following SA rule which is supposed to block base64
encoded mails:

This may be dangerous.  If someone doesn't wish to use 8bit text then
base64 encoding of UTF-8 is a sensible choice; QP is very inefficient
unless the text is almost completely ASCII.

body                EN_BASE64_B        /(Content-Transfer-Encoding:
base64\sContent-Type: text\/(plain|html);
charset="?utf-8"?)|(Content-Type: text\/(plain|html);
charset="?utf-8"?\sContent-Transfer-Encoding: base64)/i
describe             EN_BASE64_B        TEXT OR HTML B64 ENCODED
score                 EN_BASE64_B        5

this is the mail that i want to stop:

the rule don't match for this mail, but it match when i had an empty
line like this:
How can i do to match the both, with the empty line and without it?

body rules check only the text that's visible in a mail client
(including the subject text). This rule only works at all if you make
the mime unparsable.

For mime you need "full" instead of "body". You then need an
explicit \n between lines.

I agree with RW about the risk of FPs from that approach, particularly if you have international correspondents.

However if you really want to do that, you need to use the "mimeheader" kind of rule. It works like a regular message 'header' type of rule but processes mime headers within the message contents.

For example, to catch messages with a particular mime attachment file name I have a rule:

mimeheader L_BANK_PHISH1        Content-Disposition =~ m!attachment; 

Dave Funk                                  University of Iowa
<dbfunk (at) engineering.uiowa.edu>        College of Engineering
319/335-5751   FAX: 319/384-0549           1256 Seamans Center
Sys_admin/Postmaster/cell_admin            Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{

Reply via email to