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.
