Page 1 of 1

How to "source" a .conf file

Posted: 25 Jul 2022 17:58
by max_of_tl
Hi,

Does anyone know if there is an easy way to "source" a mailscanner .conf file from another? Like for example, if I wanted to include some special rules for a certain group of e-mails/domains - I could just import the changes to the main ruleset.

Currently I have 2 rulesets for filename.rules.conf - they're almost identical except a couple lines. I'd rather not have to explain via comments that these 2 files need to be modified in tandem, except those 2 rules that are different.

Also, offhand - does anyone know if the first rule you hit is what counts - or is it the last. Or is it the first deny you hit that denies you but you have to pass all the rest? I've been using it a few years and still not sure how it works exactly.

Thanks

Re: How to "source" a .conf file

Posted: 09 Aug 2022 07:19
by pdwalker
max_of_tl wrote: 25 Jul 2022 17:58Does anyone know if there is an easy way to "source" a mailscanner .conf file from another? Like for example, if I wanted to include some special rules for a certain group of e-mails/domains - I could just import the changes to the main ruleset.
That's called "include" and I don't believe it is supported.
max_of_tl wrote: 25 Jul 2022 17:58Also, offhand - does anyone know if the first rule you hit is what counts - or is it the last. Or is it the first deny you hit that denies you but you have to pass all the rest? I've been using it a few years and still not sure how it works exactly.
Good question! I've wondered this myself. It's easy enough to test. Let's see:

Test 1: adding this to /etc/MailScanner/filename.rules.conf

Code: Select all

allow   \.testing$   testing extension allowed               test extension to deliver
deny    \.test.*$    testing extension denied                test extension to not deliver
send two emails, one with an attachment called "mailscanner.testing" and "mailscanner.test"

results:
allowed: mailscanner.testing
denied: mailscanner.test

Test 2: change the order of the instructions

Code: Select all

deny    \.test.*$    testing extension denied                test extension to not deliver
allow   \.testing$   testing extension allowed               test extension to deliver
and then resend the messages.

results:
allowed: mailscanner.testing
denied: mailscanner.test


Conclusion:

The order doesn't seem to matter. What seems to matter is how close the match is to what you are testing. Since .testing$ is a more exact match than \.test*$, that rule took priority over the wildcard rule.

Also, I tested with "mailscanner.testin" and it was denied, just as I expected it would be.