Re: Custom rule don't match without empty line before the string!
On 2018-02-23 (02:15 MST), saqariden wrote: > > our mailing service is not for external use, So the users are not supposed to > send or receive B64 encoded mails. I've never seen anyone *intentionally* sent base64 mails (I mean, people, not spammers). That is a decision made by the MUA. Sounds like you may be trying to solve the wrong problem. -- I've got a sonic screwdriver! Yeah? I've got a chair! ... Chairs *are* useful.
Re: Custom rule don't match without empty line before the string!
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.
bodyEN_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_BTEXT OR HTML B64 ENCODED
score EN_BASE64_B5
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_PHISH1Content-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.
Re: Custom rule don't match without empty line before the string!
On 2018-02-22 (07:54 MST), saqariden wrote: > > I have the following SA rule which is supposed to block base64 encoded mails: Wow. You are going to block a lot of legitimate email that way. > bodyEN_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 you need to be looking at the mime headers, not simply scanning the plaintext body. In fact, Don't think the plaintext body is even available to spam assassin rules, so those lines will never match as you have them. Heck, don't know if the encoding type is available at all to SA because... well, why would it. How a message is encoded is not a spam indicator. You can do this with other tools in your MTA (postfix) or you LDA (procmail), but it's a very bad idea. My personal account has 1,770 base64 encoded messages out of 90,111. I know I would not be happy to have missed those 1,770 message. -- We are born naked, wet and hungry; then it's all downhill.
Re: Custom rule don't match without empty line before the string!
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.
> >
> >
> >> bodyEN_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_BTEXT OR HTML B64 ENCODED
> >> score EN_BASE64_B5
> >>
> >> 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_PHISH1Content-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.
Re: Custom rule don't match without empty line before the string!
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.
bodyEN_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_BTEXT OR HTML B64 ENCODED
score EN_BASE64_B5
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_PHISH1Content-Disposition =~ m!attachment;
filename="[\w\s\d._-]{1,30}verification\.html?"$!i
--
Dave Funk University of Iowa
College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include
Better is not better, 'standard' is better. B{
Re: Custom rule don't match without empty line before the string!
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. > bodyEN_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_BTEXT OR HTML B64 ENCODED > score EN_BASE64_B5 > > 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.
Custom rule don't match without empty line before the string!
Hello guys, I have the following SA rule which is supposed to block base64 encoded mails: bodyEN_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_BTEXT OR HTML B64 ENCODED score EN_BASE64_B5 this is the mail that i want to stop: -- (... header header...) X-Scanned-By: MIMEDefang 2.79 # last header line here --Boundary_(ID_xx) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8hIA0KDQpIYXZlIHlvdSAgc2VlbiAgdGhpcz8gIFlvdSd2ZSBnb3Qg dG8gdGFrZSAgYSBsb29rLCB0aGF0J3MgYXdlc29tZSwgcmVhZGluZyAgbW9y ZSBoZXJlIGh0dHA6Ly93d3cuZHVydXNhbGlzLmx0L2JjaC5waHA/a3lnDQoN= --Boundary_(ID_IcM7JgudOk13I7fXE7a3Zw)-- - the rule don't match for this mail, but it match when i had an empty line like this: --Boundary_(ID_xx) #empty line here Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 How can i do to match the both, with the empty line and without it? THANK'S Regards, S.AQARIDEN. Signature Academique
