You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by saqariden <sa...@ac-montpellier.fr> on 2018/02/22 14:54:45 UTC

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:


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:

--------------------------
(... header header...)
X-Scanned-By: MIMEDefang 2.79 # last header line here


--Boundary_(ID_xxxxxx)
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_xxxxxx)
    #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

Re: Custom rule don't match without empty line before the string!

Posted by "@lbutlr" <kr...@kreme.com>.
On 2018-02-22 (07:54 MST), saqariden <sa...@ac-montpellier.fr> 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.

> 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

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!

Posted by "@lbutlr" <kr...@kreme.com>.
On 2018-02-23 (02:15 MST), saqariden <sa...@ac-montpellier.fr> 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!

Posted by saqariden <sa...@ac-montpellier.fr>.

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.

Re: Custom rule don't match without empty line before the string!

Posted by RW <rw...@googlemail.com>.
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.




Re: Custom rule don't match without empty line before the string!

Posted by David B Funk <db...@engineering.uiowa.edu>.
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; filename="[\w\s\d._-]{1,30}verification\.html?"$!i



-- 
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{

Re: Custom rule don't match without empty line before the string!

Posted by RW <rw...@googlemail.com>.
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.