Hidden Features - SpamTagger/SpamTagger-Plus GitHub Wiki
Context for MailCleaner Users
Historically, many of the MailCleaner features discussed on this page were achievable through the modification of the source code on a running system. This had always been strongly discouraged for MailCleaner because the source was controlled by Git and modifications could break updates or could break mailflow in real time. In SpamTagger Plus, such changes are generally not possible at all after we adopted read-only Bootc filesystem images.
You can still potentially build your own SpamTagger Plus images with modifications and use bootc switch to rebase an existing machine to your modified version, but this would probably be quite a bit of work to maintain for changes that you are bound to share anyways.
Instead, as many hidden features as possible will be made configurable through a writable directory (/etc/spamtagger). If you have additional modifications which you would like in the source, you are encouraged to upstream those modifications so that they can be included as official features (hidden or not).
The following are a list of features which are too niche or dangerous to expose directly within the WebUI but which have specific accommodations in the source code. Relevant warnings are provided but please use these at your own risk.
Full Whitelist
Technical details
The full whitelist feature functions by being the highest priority router in the Incoming MTA configuration. This ensures that all SMTP access controls are not evaluated and instead of forwarding to the Filtering MTA, this router will forward directly to the Outgoing MTA meaning. Unlike regular whitelists, which are still evaluated by all of the regular filters with the result being ignored, a full whitelist bypasses all of these checks entirely.
Configuration
Mail will be fully whitelisted if it meets 2 criteria:
- The sending mail server host has to be in the file
/etc/spamtagger/exim/full_whitelisted_hosts.list
Shorthands and CIDR notation are allowed according to the same conditions as other hostlist boxes as discussed here
- The sending mail address has to be in the file
/etc/spamtagger/exim/full_whitelisted_senders.list
Wildcard addresses can be allowed with '*'. For example you can whitelist a domain with *@domain.com. This uses Exim address list formatting which is simplest to implement one-per-line in a file context.
Legacy Support
MailCleaner previously had this feature available using the contents of Configuration->AntiSpam->Trusted IPs/Networks instead of the full_whitelisted_hosts.list file. If that file does not exist then this field will still be used in order to support legacy configurations.
It is recommended that you migrate to the dedicated file if you have been using the "Trusted IPs/Networks" field because adding the hosts to that field necessarily means that all other mail from those hosts will skip basic spam filtering also. For example, if you add Office365 to the host list so that you can fully whitelist a single address who use that service, you would also be skipping SpamC, PreRBL, UriRBL, etc. for all other email originating from those IPs. Using the dedicated file does not result in this problem.
More Frequent Summary Reports
SpamTagger Plus sends summaries about the mail caught in spam filters per day, week or month.
If you want to get it more often within any of those cycles, this is doable but there are STRONG downsides since the code sending these summaries was not meant to be use that way.
To avoid getting those downsides, we recommend just using the Tag mode of SpamTagger Plus. The mail server or user's mail reader should be able to be configured to direct messages with the Subject tag directly to a Junk folder. This will allow for immediate access to the messages, without having them clog up the Inbox or getting confused with legitimate messages.
If necessary, an admin could schedule additional reports, since this the existing reports are simply a child process of the regular cron task anyways. For this example, let us say you want your user to get the summaries every 2 hours during the workday and that your existing daily tasks run at 09:00. This can be done by supplementing for the remaining instances with another cron task. Edit the crontab file with:
crontab -e
Then create a new task like:
0 11,13,15,17 * * * /usr/spamtagger/bin/send_summary.pl [email protected] 3 0
In this example [email protected] is the user who will be getting the additional reports, the 3 indicates the frequency type (0 = one-time commandline usage; 1 = monthly; 2 = weekly; 3 = daily) and 0 indicates the number of preceding days to include (0 means "since the start of yesterday"). The rest is standard cron formatting and you can see the cron documentation for more.
The crontab should only be modified on the master server of a cluster. In the above example, you can set a mail address like [email protected], a whole domain like spamtagger.org or -a if this would have to be done for all users of all domains.
As noted briefly, the reports include incidents since the start of the day, for as many days back as you define. So, this means that multiple reports per day can be tedious since the copy sent at 17:00 will contain all of the same entries as 15:00, plus any received in the last 2 hours. Even if there was nothing caught in the last 2 hours, SpamTagger Plus does not keep track of previous reports, so it will send the identical notification again.