[TUTORIAL] Advancing Proxmox Mail Gateway (especially Spam and Virus Detection)

I set the same LFTP indicated here.

but I am receiving the email, but also saying:

TERM environment variable not set.
 
Petr Stepanek said:
After a lot of tests and RelayCountry.pm script debugging I found final solution for GeoIP2. It is really easy but lack of documentations makes it a lot more demanding.

I added GeoIP2 CPAN module:
Code: 
perl -MCPAN -e shell
install GeoIP2::Database::Reader

Edited `custom.cf`:
Code: 
nano /etc/mail/spamassassin/custom.cf

And enabled GeoIP2:
Code: 
country_db_type GeoIP2
country_db_path /usr/share/GeoIP/GeoLite2-Country.mmdb

After all it is better to test it:
Code: 
spamassassin -D --lint 2>&1 | grep -i --color relaycountry

Does somebody have idea how to show RelayCountry header in emails? It looks like SA implementation in PMG is not able to add header at all.
Click to expand...

Thanks for the info, but im getting an issue after running
Code: 
echo "test" | spamassassin -D pyzor 2>&1 | less

i got this error
Code: 
Jan  5 21:36:43.516 [2744] warn: config: created user preferences file: /root/.spamassassin/user_prefs
Jan  5 21:36:43.537 [2744] dbg: pyzor: network tests on, attempting Pyzor
Jan  5 21:36:48.746 [2744] info: config: country_db_path "/usr/share/GeoIP/GeoLite2-Country.mmdb" is not accessible
Jan  5 21:36:48.746 [2744] info: config: SpamAssassin failed to parse line, "/usr/share/GeoIP/GeoLite2-Country.mmdb" is not valid for "country_db_path", skipping: country_db_path /usr/share/GeoIP/GeoLite2-Country.mmdb

whats odd is that i checked /usr/share and did not see GeoIP folder

Thank you
 
Any easy way to remove all rules created by custom channels ?
Getting too many false-positives from schaal-it.
First step - remove sa-update from cron.hourly, what other steps are required ?

Found the answer.
/var/lib/spamassassin/3.004002 - includes custom ruleset.

killmasta93 said:
Update: So today i got a few cron error
Code: 
invalid regexp for rule SCHAALIT_HEADER_5752: /\Part num your Hacked phone!/: Can't find Unicode property definition "a" in regex; marked by <-- HERE in m/\Pa <-- HERE rt num your Hacked phone!/

config: warning: description exists for non-existent rule SCHAALIT_HEADER_5752

This is the SA-update

Code: 
#!/bin/sh

# schaal @it
#
# Simple script to update SpamAssassin

SYSLOG_TAG=sa-update

compile=0

logger -d -t $SYSLOG_TAG "Start SA-Update"

sa-update --nogpg
retval="$?"
if [ $retval -eq 0 ]; then compile=1; fi


sa-update --nogpg --channel updates.spamassassin.org
retval="$?"
if [ $retval -eq 0 ]; then compile=1; fi

sa-update --nogpg --channel sa.zmi.at
retval="$?"
if [ $retval -eq 0 ]; then compile=1; fi

sa-update --nogpg --channel sa.schaal-it.net
retval="$?"
if [ $retval -eq 0 ]; then compile=1; fi

sa-update --nogpg --channel spamassassin.heinlein-support.de
retval="$?"
if [ $retval -eq 0 ]; then compile=1; fi

if [ $compile -eq 1 ]; then
    logger -d -t $SYSLOG_TAG "SA-Update found"
    sa-compile --quiet 2>/dev/null
    systemctl restart pmg-smtp-filter
else
    logger -d -t $SYSLOG_TAG "No SA-Update found"
fi
Click to expand...
 
Last edited:
heutger said:
As mentioned in post #225 I just added a script to update KAM.cf and add nonKAMrules.cf as KAM.cf isn't updated really often by PMG and nonKAMrules.cf isn't included at all. Hopefully, this updates would also be adopted to PMG itself. Steps performed are just easy:

Code: 
vi /etc/cron.daily/KAM-update
/etc/cron.daily/KAM-update

And the content of /etc/cron.daily/KAM-update (daily updating is enough) is as followed (adopted from sa-update from before):

Code: 
#!/bin/sh

# KatyComputer
#
# Simple script to update KAM rules

SYSLOG_TAG=KAM-update

compile=0

logger -d -t $SYSLOG_TAG "Start KAM-Update"

md5_old=$( md5sum /usr/share/spamassassin-extra/KAM.cf )
wget -q -N -P /usr/share/spamassassin-extra http://www.mcgrail.com/downloads/KAM.cf
md5_new=$( md5sum /usr/share/spamassassin-extra/KAM.cf )
if [ "$md5_old" != "$md5_new" ]; then compile=1; fi

md5_old=$( md5sum /usr/share/spamassassin-extra/nonKAMrules.cf )
wget -q -N -P /usr/share/spamassassin-extra http://www.mcgrail.com/downloads/nonKAMrules.cf
md5_new=$( md5sum /usr/share/spamassassin-extra/nonKAMrules.cf )
if [ "$md5_old" != "$md5_new" ]; then compile=1; fi

if [ $compile -eq 1 ]; then
    logger -d -t $SYSLOG_TAG "KAM-Update found"
    sa-compile --quiet 2>/dev/null
    systemctl restart pmg-smtp-filter
    systemctl restart spamassassin
else
    logger -d -t $SYSLOG_TAG "No KAM-Update found"
fi
Click to expand...

I am on PMG 6.2-5, and do not use the Filter, so I am removing the line for restarting Spamassassin - but my question is, are these rules in the current directory also used by 6.2-5 in it's Spam Assassin @heutger
 
thebiggeek said:
I am on PMG 6.2-5, and do not use the Filter, so I am removing the line for restarting Spamassassin - but my question is, are these rules in the current directory also used by 6.2-5 in it's Spam Assassin @heutger
Click to expand...
Why shouldn't the rules do it with 6.2.5? See not reason for your question... You can safely skip the SA restart line (like you already did!), as it's not required by PMG default install, only when you use the additional miltered setup....

@heutger and @Stoiko Ivanov :
And I really wonder, why the tweaks use systemctl restart pmg-smtp-filter and not systemctl reload pmg-smtp-filter?

Shouldn't the systemctl reload pmg-smtp-filter just do the same, to apply SA-Ruleset changes on the fly, without interrupting the whole pmg-filter-service process (and creating new PID) when executing systemctl restart pmg-smtp-filter?
 
Last edited:
ittk said:
Why shouldn't the rules do it with 6.2.5? See not reason for your question... You can safely skip the SA restart line (like you already did!), as it's not required by PMG default install, only when you use the additional miltered setup....

@heutger and @Stoiko Ivanov :
And I really wonder, why the tweaks use systemctl restart pmg-smtp-filter and not systemctl reload pmg-smtp-filter?

Shouldn't the systemctl reload pmg-smtp-filter just do the same, to apply SA-Ruleset changes on the fly, without interrupting the whole pmg-filter-service process (and creating new PID) when executing systemctl restart pmg-smtp-filter?
Click to expand...

The reason I ask this question is because, when I do

spamassassin -D --lint 2>&1 | grep -i --color KAM.cf - I can see that it is loading KAM.cf as shown in dbg: config: using "/usr/share/spamassassin-extra/KAM.cf" for included file

but when I do spamassassin -D --lint 2>&1 | grep -i --color nonKAMrules.cf I get no output. I do not have a separate MILTER based spamassassin setup, and am using only the one with PMG only. I had also added some more custom Rules that I need like the bogus-virus-warnings.cf and even they are not getting loaded - hence the question.

I believe I should edit /etc/mail/spamassassin/local.cf as instead of including the extra's directory - it only includes the KAM.cf there
 
thebiggeek said:
pamassassin -D --lint 2>&1 | grep -i --color KAM.cf
Click to expand...
Petr Stepanek said:
Thank you for your time and that you are trying to help me.

After some tests I found that the problem was in my misunderstanding. I thought that if I add to "custom.cf" I will see "X-SPAM_Relay-Country" in email headers but I will see only "RELAYCOUNTRY_GOOD" or "RELAYCOUNTRY_BAD" if it meet right policy.

So "add_header all" rule will be never shown in email header?

Edit: And one really important thing is that I had to restart "pmg-smtp-filter" service everytime when I edited "custom.cf" file. Problem was that I tested every change by "spamassassin -D" command which show every change in "custom.cf" immediately, instead of "pmg-smtp-filter" service which need to be restarted.
Click to expand...
Hi, Were you able to get get the Header working - I would like to see the Relay Country in all my emails.
 
@ittk @thebiggeek I recently always did restart on service changes, but maybe @Stoiko Ivanov could answer, when reload is enough and when restart is really required. I believe, that config changes should be performed by a restart, maybe just value changes a reload will be enough but enabling additional modules a restart would be better, I'm unsure. As I also recompile the rules before I perform my restart, I believe, a restart is much more safe, but again, I didn't found anything about the difference on reload or restart, I just found, that in some postings about amavis, which is somehow a similar wrapper as pmg-smtp-filter to spamassassin, just performing a reload has been told to be enough.

About adding X-SPAM_Relay-Country I'm unsure if the reason why this header is not been added is also because of pmg-smtp-filter wrapping SpamAssassin as pmg-smtp-filter is also performing own spam score headers than e.g. my miltered SpamAssassin, so maybe they suppress adding the header. Again @Stoiko Ivanov may help here.
 
I have also started noticing a bug - whatever additional rules I add to the file /etc/mail/spamassassin/local.cf keep getting removed, the only rule line that survives this is the KAM.CF but others get removed, not sure how to handle this, maybe @Stoiko Ivanov can give inputs? I am currently on 6.2-5

I have also started publishing some of my own Custom Rules in case someone needs - these rules are from spams messages that I have seen that pass by and are hard to detect. Typically sent by new senders from Yahoo / Gmail and hence they dont' fail anything - other than the content. The Rules are available here on my GitHub - Thanks to the script by @heutger I have been able to setup a Daily update of these to the server - now only to figure out why the Include Statements from my local.cf are getting removed
 
Some updates @Stoiko Ivanov I added the links in /usr/share/spamassassin-extras/ into the customs.cf instead of local.cf and now changes from there are also disappearing. This is only happening on the machine where I updated pve-kernel-5.4 (pve-kernel-5.44-2-pve) and not on the machine were update is pending (I have 2 machines setup in cluster)
 
To find what could be causing this, I upgraded my second node in the cluster too and I am loosing any settings I make in the custom.cf or local.cf
 
ittk said:
And I really wonder, why the tweaks use systemctl restart pmg-smtp-filter and not systemctl reload pmg-smtp-filter?
Click to expand...
Upon reload the rule-database and configuration are loaded, however the SpamAssassin rules are not reloaded.
In those cases a restart should be carried out.
OTOH this should not affect mailprocessing - the pre-forked children, which at that moment inspect a mail with finish doing so before exiting.

I hope this explains it.
 
  • Like
Reactions: heutger and thebiggeek
Thank you @heutger for your reference of Invaluement - I am right now testing these out. In the meantime, there were a few questions I had from your Advancing setup and thought will ask you here

1. I notice that you are not using Greylisting - in the pmgconfig dump you have shared, your pmg.mail.greylist = 0 is shown - maybe it changed over time - I have personally found that greaylist keeps away a bit of Spam - but have also found many mail servers are not complaint - What is your opinion here?

2. I notice you are not testing for SPF - I understand that a lot of people are not complaint, I would love to hear more about you on your setting of pmg.mail.spf = 0

3. For TLS - you are using both TLS LOG and TLS Header - Can you elaborate more on these settings and how this helps pmg.mail.tlsheader=1, pmg.mail.tlslog = 1

4. For PMG Verify Receivers, I am unable to find documentation - Does this require me to map each individual email id on the PMG servers? mg.mail.verifyreceivers = 550

5. Can you help me understand the setting and it's impact for pmg.mail.rejectunknown = 0
 
thebiggeek said:
Thank you - I will read up about this - so just to get it correct - all changes to be made for anything are to be in templates, but changes to file /etc/mail/spamassassin/custom.cf are ok?
Click to expand...
yes that's the way it should be IIRC
 
  • Like
Reactions: thebiggeek
thebiggeek said:
Thank you @heutger for your reference of Invaluement - I am right now testing these out. In the meantime, there were a few questions I had from your Advancing setup and thought will ask you here

1. I notice that you are not using Greylisting - in the pmgconfig dump you have shared, your pmg.mail.greylist = 0 is shown - maybe it changed over time - I have personally found that greaylist keeps away a bit of Spam - but have also found many mail servers are not complaint - What is your opinion here?

2. I notice you are not testing for SPF - I understand that a lot of people are not complaint, I would love to hear more about you on your setting of pmg.mail.spf = 0

3. For TLS - you are using both TLS LOG and TLS Header - Can you elaborate more on these settings and how this helps pmg.mail.tlsheader=1, pmg.mail.tlslog = 1

4. For PMG Verify Receivers, I am unable to find documentation - Does this require me to map each individual email id on the PMG servers? mg.mail.verifyreceivers = 550

5. Can you help me understand the setting and it's impact for pmg.mail.rejectunknown = 0
Click to expand...

You're welcome, best wishes to Rob. Maybe he should negotiate with Proxmox team to offer his list with a special discount as an option to their subscription packages (maybe I should signup as a reseller for Proxmox and built the packages myself).

1. I already mentioned to Proxmox team (maybe @Stoiko Ivanov will discuss on that again, as it recently had been declined, but maybe times changed) that Greylisting in the current times (maybe 10+ years before it was different) is useless as been (usually) implemented. It result in somehow any mail get delayed, which is no good behavior in current times (where everything needs to be fast or e.g. timeouts may occur on password resets etc.). To "disable" Greylisting based on SPF also does not make sense as SPF is also no good solution. If enabled also -all rules apply, which may get you in trouble as SPF is not well implemented. Forwarded or group mails (also Proxmox had that issue BTW) would result in a reject on -all, some configured SPF and forgot about it (because of its useless state) and finally most spam reaching my inbox is from Google Mail, Outlook.com or Yahoo Mail, which is well DKIM signed and with valid SPF records, so it's no indicator for spam or no-spam any more. But(!) there is only one setup, which really makes much sense in conjunction with Greylisting, which I saw on rspamd, but isn't adopted by Proxmox (yet?). If a mail has a particular spam score (maybe with post-queue filtering that did not make sense or was somehow impossible, with pre-queue filtering it's possible now), greylist that mail and just that mail. You may ask why? So you may have three states of a mail: mail is (somehow seriously sure) ham, let's pass that one, fast and without any hassle, mail is (somehow seriously sure) spam, let's reject that, fast and without any hassle, mail is unsure, maybe spam or not, greylist that one with the benefit, that the sender need to retry and the hope, if the sender retry and the mail is really spam, the sender is now already listed on necessary blacklists, so it get then rejected or it's still unsure and maybe (with a higher percentage of success) ham, then let it pass. I call that conditional greylisting and that's the only way, I believe greylisting has an existential reason today.

2. As mentioned before and sorry for being such direct now, I believe in some of the current techniques are bullshit. This ones are: SPF, DKIM, DMARC (as result of SPF and DKIM), DANE, DNSSEC. The reasons are somehow the same (as mentioned in my posts) failed by design. And I really don't understand, why this failures are often done again and again, as e.g. SPF is killed by forwarding, mail groups, etc. DMARC has the same design failure and requires ARC to fix that. Why doing the same failure again and again? However, that's the reason, why I disabled SPF (on my commercial trial setup, on my private playground one it's sometimes enabled).

3. Just for debugging purposes. You may keep it off. I somehow used TLS log very often at the time of optimizing my TLS cipher suite setting.

4. Verify receivers needs to be supported by the destination server (and if exist the full path until the destination server). Then PMG will perform checks to such server(s), if the address get reported as unreachable or not, so you could safely reject a message for not existing recipients instead of having anyone in the flow sending NDR, which may result in getting your infrastructure recognized as backscatterer or more unserious and in Germany illegal any server in the path tries to report back and is unable to do so, finally resulting in suppressing the message without any response. Code 550 is hard, 450 would result in retries.

5. As documented unknown clients are rejected (should be enabled in my example configuration, isn't it?). However be careful with this setting and read my documentation on that. I changed the behavior on my commercial trial (not on my private playground) as the default setting provided by PMG (@Stoiko Ivanov maybe Proxmox should offer both options) is a FCrDNS check, so the client IP need to resolve to a hostname and vice versa this hostname need to resolve back to the same IP address. On particular clustered setups, that may fail so the check will result in unnecessary rejects. So I changed that in adjusting the template to reject_unknown_reverse_client_hostname which only perform the IP to hostname check but omit the consistency check back to the IP address, which result in less false-positives. As PMG offers sometimes options like 450 or 550 (however not on all settings, I therefor did manually some more), PMG should also offer the harder or softer option of reject_client_hostname with rejectunknown.

Hope, that helps! ;-)
 
heutger said:
You're welcome, best wishes to Rob. Maybe he should negotiate with Proxmox team to offer his list with a special discount as an option to their subscription packages (maybe I should signup as a reseller for Proxmox and built the packages myself).

1. I already mentioned to Proxmox team (maybe @Stoiko Ivanov will discuss on that again, as it recently had been declined, but maybe times changed) that Greylisting in the current times (maybe 10+ years before it was different) is useless as been (usually) implemented. It result in somehow any mail get delayed, which is no good behavior in current times (where everything needs to be fast or e.g. timeouts may occur on password resets etc.). To "disable" Greylisting based on SPF also does not make sense as SPF is also no good solution. If enabled also -all rules apply, which may get you in trouble as SPF is not well implemented. Forwarded or group mails (also Proxmox had that issue BTW) would result in a reject on -all, some configured SPF and forgot about it (because of its useless state) and finally most spam reaching my inbox is from Google Mail, Outlook.com or Yahoo Mail, which is well DKIM signed and with valid SPF records, so it's no indicator for spam or no-spam any more. But(!) there is only one setup, which really makes much sense in conjunction with Greylisting, which I saw on rspamd, but isn't adopted by Proxmox (yet?). If a mail has a particular spam score (maybe with post-queue filtering that did not make sense or was somehow impossible, with pre-queue filtering it's possible now), greylist that mail and just that mail. You may ask why? So you may have three states of a mail: mail is (somehow seriously sure) ham, let's pass that one, fast and without any hassle, mail is (somehow seriously sure) spam, let's reject that, fast and without any hassle, mail is unsure, maybe spam or not, greylist that one with the benefit, that the sender need to retry and the hope, if the sender retry and the mail is really spam, the sender is now already listed on necessary blacklists, so it get then rejected or it's still unsure and maybe (with a higher percentage of success) ham, then let it pass. I call that conditional greylisting and that's the only way, I believe greylisting has an existential reason today.

2. As mentioned before and sorry for being such direct now, I believe in some of the current techniques are bullshit. This ones are: SPF, DKIM, DMARC (as result of SPF and DKIM), DANE, DNSSEC. The reasons are somehow the same (as mentioned in my posts) failed by design. And I really don't understand, why this failures are often done again and again, as e.g. SPF is killed by forwarding, mail groups, etc. DMARC has the same design failure and requires ARC to fix that. Why doing the same failure again and again? However, that's the reason, why I disabled SPF (on my commercial trial setup, on my private playground one it's sometimes enabled).

3. Just for debugging purposes. You may keep it off. I somehow used TLS log very often at the time of optimizing my TLS cipher suite setting.

4. Verify receivers needs to be supported by the destination server (and if exist the full path until the destination server). Then PMG will perform checks to such server(s), if the address get reported as unreachable or not, so you could safely reject a message for not existing recipients instead of having anyone in the flow sending NDR, which may result in getting your infrastructure recognized as backscatterer or more unserious and in Germany illegal any server in the path tries to report back and is unable to do so, finally resulting in suppressing the message without any response. Code 550 is hard, 450 would result in retries.

5. As documented unknown clients are rejected (should be enabled in my example configuration, isn't it?). However be careful with this setting and read my documentation on that. I changed the behavior on my commercial trial (not on my private playground) as the default setting provided by PMG (@Stoiko Ivanov maybe Proxmox should offer both options) is a FCrDNS check, so the client IP need to resolve to a hostname and vice versa this hostname need to resolve back to the same IP address. On particular clustered setups, that may fail so the check will result in unnecessary rejects. So I changed that in adjusting the template to reject_unknown_reverse_client_hostname which only perform the IP to hostname check but omit the consistency check back to the IP address, which result in less false-positives. As PMG offers sometimes options like 450 or 550 (however not on all settings, I therefor did manually some more), PMG should also offer the harder or softer option of reject_client_hostname with rejectunknown.

Hope, that helps! ;-)
Click to expand...

TLDR: Thank you for your inputs - I am disabling SPF checks and also grey listing, will keep you updated on what happens next.

That was a long read, and I thank you for taking the time out to answer my queries. Reference Bundling Invaluement lists inside Proxmox maybe a good idea, but that will depend on these two parties. Am glad that we can integrate his solution - thanks to you making it simpler, and yes may all the power be to Rob. (About you bundling a solution - I did see a thread where there was a mention someone wanted you to consult them - I would love to speak about this - I remember when I started using Mail Scanner the first time around, there were a few people who launched services based on Mail Scanner)

1. Reference Greylist. you make a good point, and add that with SPF - yes a lot of emails get rejected. I am not sure about SPF. I have actually seen hosting companies and clients getting tighter about SPF - I understand it's not fully out there, but then the debate is - people will implement only if you start returning emails. For DKIM - That is still a far cry - not all servers support it - and I personally started testing PMG as an outbound relay for DKIM Signing before switching the Antispam capabilities to it. Let me see if I find a solution and or alternative to SPF. I like the way you are thinking of the Greylist and the absolute SPAM/HAM and am sure this is an area where there will be some stuff to be done.

2. I am not a big believer in DMARC / DKIM and DANE - I think these were just pushed down our throats (like. IPV6) and we are far far away to see proper implementations. DNS Servers by virtue of their design are old and aging and no one is really doing much on this front (I recently migrated our BIND Servers setup in 1995 to Power DNS - and thought I will find a good front end - but na.. I am still back to editing BIND files that have 2000+ Lines for historical reasons, and other deployments that have happened since 1995). So I get it - that it's just not laziness but the porting of essential services are a complex thought, add to that legacy systems (On Premise Exchange for example does not support DKIM/DMARC) - Old Zimbra and QMAIL / Postfix servers still have a problem doing this, and as you said - one looses this in mailing lists / groups / forwards.

3. I would love to know more about your TLS experience, and what you are doing here - maybe you could setup a thread on that, like you did for Advancing and for your Filtering lists.

4. I will let the Verify Receivers bit for now, I am anyway wary of this. I use INUMBO for some of our work and it needs to list each email id every time you create one. I love what INUMBO and HALON are doing, and they have priced it nicely too, but making sure you add the users at both the places, always result in a chaos. Ensuring full path is also a challenge, I would rather send NDR's.

5. Thanks got the Unknown client bit. I actually love that setting only on Direct Mail Servers and yes with Proxy's such as PMG delivering email and SPF not setup properly this may become a challenge.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back