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
I have the following SA rule which is supposed to block base64
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:
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
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;
mimeheader rules wont work in this case because you need to
check both Content-Type and Content-Transfer-Encoding in the same mime
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)