On 22/02/2018 17:48, RW wrote:
On Thu, 22 Feb 2018 10:35:48 -0600 (CST)
David B Funk wrote:

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"?)|(mimeheader: 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;
filename="[\w\s\d._-]{1,30}verification\.html?"$!i


mimeheader rules wont work in this case because you need to
check both Content-Type and Content-Transfer-Encoding in the same  mime
section.



Thank you for the answers, it help us so much.
our mailing service is not for external use, So the users are not supposed to send or receive B64 encoded mails. There is no other solution except "full"? I avoid it because it requires additional resources. (1M mails/day to scan)

Regards.

Reply via email to