efa-project.org

Posted: **31 Mar 2020 06:38**

Hello everybody,

i have a problem with filenames and special chars!

I am denying Office Documents which can contain macros in /etc/MailScanner/filename.rule.conf

Code: Select all

deny	\.doc$	Office Makro Documents	Office Makro Documents
deny	\.docm$	Office Makro Documents	Office Makro Documents
deny	\.dot$	Office Makro Documents	Office Makro Documents
deny	\.dotm$	Office Makro Documents	Office Makro Documents

So docx is valid, because it can not contain any macros in it! Works fine so far.

If a user is sending a docx with a short or "normal" name like "2020.03.31_contract_for_Mueller.docx" or "20200331contractforMueller.docx" everything works well.

But if the document has some special german chars in its filename like "2020.03.31_contract_for_Müller.docx" or "20200331contractforMüller.docx" it is blocked inside efa with the message "Office Makro Documents".

The reason seems to be the german "ü" in the filename.

Someone can help me out?

I'm using efa 3.0.2.6

Posted: **02 Apr 2020 16:57**

No one can help? C'mon!

I really need the swarm knowledge of the community!

Greetz

Posted: **08 Apr 2020 08:00**

Can you confirm that these are the only references to "Office Makro Documents" in your /etc/Mailscanner directory?

Posted: **12 Apr 2020 11:55**

Yes i can confirm this.

Posted: **15 Apr 2020 07:57**

I'm trying to reproduce your problem.

What version of EFA are you running?

Can you look at the mail messages? How are the document names encoded in the email?

For example, I've sent myself 2 documents in 2 messages, and this is what I see

2020.03.31_contract_for_Mueller.docx

Code: Select all

Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
        name="2020.03.31_contract_for_Mueller.docx"
Content-Disposition: attachment;
        filename="2020.03.31_contract_for_Mueller.docx"

2020.03.31_contract_for_Müller.docx

Code: Select all

Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
        name="=?UTF-8?B?MjAyMC4wMy4zMV9jb250cmFjdF9mb3JfTXXMiGxsZXIuZG9jeA==?="
Content-Disposition: attachment;
        filename="=?UTF-8?B?MjAyMC4wMy4zMV9jb250cmFjdF9mb3JfTXXMiGxsZXIuZG9jeA==?="

Next, I've added the following ruleset into my filename.rule.conf file:

Code: Select all

# testing purposes only
deny	\.STOP.doc$	Office Makro Documents	Office Makro Documents
deny	\.STOP.docm$	Office Makro Documents	Office Makro Documents
deny	\.STOP.dot$	Office Makro Documents	Office Makro Documents
deny	\.STOP.dotm$	Office Makro Documents	Office Makro Documents

and then resent the files, after renaming them to to:

Code: Select all

2020.03.31_contract_for_Müller.STOP.docx
2020.03.31_contract_for_Mueller.STOP.docx

and they passed without problem

next, I renamed them to .doc and resent them expecting them to both be blocked

Code: Select all

2020.03.31_contract_for_Müller.STOP.doc
2020.03.31_contract_for_Mueller.STOP.doc

And as expected, they were both blocked with the following error message in the "Bad Filename Detected"

Code: Select all

    Report: MailScanner: Office Makro Documents (2020.03.31_contract_for_Mueller.STOP.doc)
    Report: MailScanner: Office Makro Documents (2020.03.31_con.doc)

Interesting - the document with the encoded filename has been mangled in the report, so it would appear that there is a bug of some sort in the handling of encoded filenames.

This doesn't reproduce your exact problem, but it may be related. There definitely seems to be some kind of bug. Also, why are you getting the rule triggered on your docx files - which shouldn't happen according to your rules. Please confirm both the base OS you are using for your EFA installation and the version of EFA you have running. (I'm running an old version, so don't take my results as a good example of how EFA currently is)

I don't have time to debug it further today, but the code I need to look at is
/usr/share/MailScanner/perl/MailScanner/SweepOther.pm

Shawn, if you read this, do you have any advice how I could run this check against already stored messages with the debug statements uncommented so I could see what is happening?

Posted: **15 Apr 2020 08:47**

Thanks for the support!

I'm still on efa 3.0.2.6. efa is installed as a appliance using the ISO. So everything should be default.

I'm planning to upgrade in summer...

E-Mails are written in Outlook, sending via Exchange 2016 on premise. efa is the smart host for Exchange.

here is the Content-Type for the File "2020.03.31_contract_for_Müller.docx"

Code: Select all

Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
        name="=?iso-8859-1?Q?2020.03.31=5Fcontract=5Ffor=5FM=FCller.docx?="
Content-Description: =?iso-8859-1?Q?2020.03.31=5Fcontract=5Ffor=5FM=FCller.docx?=
Content-Disposition: attachment;
        filename="=?iso-8859-1?Q?2020.03.31=5Fcontract=5Ffor=5FM=FCller.docx?=";
        size=11284; creation-date="Tue, 14 Apr 2020 06:15:58 GMT";
        modification-date="Tue, 14 Apr 2020 06:15:59 GMT"

But in the meantime i was able to work around by simply allowing docx in /etc/MailScanner/filename.rules.conf

Code: Select all

allow	\.docx$	-	-

This seems to work *crossing the fingers*

Thank you so much!!

Posted: **15 Apr 2020 16:36**

I'm glad you found a workaround.

There is definitely a bug in the filename handler, but I won't report it unless I can reproduce the problem under the latest version of EFA/mailwatch.

I also strongly suggest that you not put off the upgrade too much longer. Centos 6 is getting very long in the tooth.

Also, I should take my own advice.

efa-project.org

Block Office Documents

Block Office Documents

Re: Block Office Documents

Re: Block Office Documents

Re: Block Office Documents

Re: Block Office Documents

Re: Block Office Documents

Re: Block Office Documents