Something.doc.pdf|.docx.pdf|.xls.pdf|.xlsx.pdf blocked (Bad Content)

[DaN]

Unfortunately a couple of senders send mails with attachments like "Something.doc.pdf|.docx.pdf|.xls.pdf|.xlsx.pdf", because they use a PDF converter "wrong".

It seems that "/etc/MailScanner/filename.rules.conf" needs a allow-rule, which allows those attachment names.

Is

Code: Select all

allow	\.doc.pdf$		-	-

and possible variations good/wise/meaningfull?

[shawniverson]

I'll go ahead and open an issue for this.

https://github.com/E-F-A/v3/issues/146

[DaN]

And today it's a "[Something].xml.pdf", which results in "Report: MailScanner: Attempt to hide real filename extension ([Something].xml.pdf) --> Bad Content



A realy dirty workaround:
add

Code: Select all

# Allow days of the week and months,xml, Excel- and Word-extensions in document names, e.g. blah.wed.doc or e.g. blah.xml.pdf
allow	\.(xml|xls|xlsx|doc|docx|mon|tue|wed|thu|fri|sat|sun)\.[a-z0-9]{3}$	-	-

in /etc/MailScanner/filename.rules.conf

[pdwalker]

I just got bitten by this problem.

There are three solutions that I can think of

1/ quick and dirty because you need it fixed now
- comment out the "Attempt to hide real filename extension" rule in /etc/Mailscanner/filename.rules.conf and archives.filename.rules.conf

2/ whitelist the senders so the spam checking is skipped

3/ have a nice elegant way of overriding the mailscanner rules that will survive upgrades

Obviously, I'd prefer #3, but I'm not sure how I'd go about it.

#2 seems to work, but I'm not sure I'd want to compromise security in this fashion. What if an internal machine starts spewing junk?

#1 clearly works, but the next upgrade would wipe out the changed rules (best case) or cause problems because the files don't match (worst case).

[darky83]

For option 3 I have already been playing with the idea how to 'keep' changes made by users.

The only way to accomplish that is if E.F.A. is in control of the changes.
This means we should build it in EFA-Config (or an webinterface) and keep all modifications in /etc/EFA-Config (or maybe even SQL)
That way we can check with updates which items have been modified and keep these settings.

An disadvantage is that it will only work if we have writen an 'change' item for that specific rule.
And another one is that it will probably take us a while to get it stable

[shawniverson]

Chiming in....

I think as long as the "hood is open," so to speak, people will customize EFA in many way that we cannot anticipate. Even with a comprehensive configuration tool, it is still going to happen...I guess we could always say "you are on your own" if we go this route and people tinker anyway....

On another note....MailScanner rules should survive upgrades unless MailScanner fundamentally changes the way the rules are formatted and parsed.

For example, in 3.0.0.7, we updated Spamassassin in such a way that existing configs were preserved.

I believe we can do the same with the next MailScanner update.

[pdwalker]

makes sense and works for me.

[pdwalker]

a year later, my mailscanner config files have survived two upgrades intact.

[jkissane]

Thanks for this info, recently people have started using Docusign internally which has been bombarding us with .doc.pdf files which were getting blocked. This rule addition makes life a lot easier.

[pdwalker]

excellent. good to hear you found the answer to your problem.

And over 4 years later, my mailscanner config files have still survived. woohoo!