Removes the comment from line 196, which enables the loading of plugins at startup again. Otherwise there would have been the need for a SIGHUP in order to load the plugins initially.
Closes#308 and #288.
* Regex fix, checkip argument & updated tld list
This patch include 3 fixes:
1) The plugin could match invalid URIs, eg. "www..example.com", which resulted in fatal plugin error, sending the incoming email directly into queue without any further scan. The regex has been fixed.
2) Some URIBLs trigger positive on any ip-address. Added new plugin argument: checkip [yes|no].
3) Updating the TLD list.
Co-authored-by: mufus <hello@mufus.com>
If the reject argument is set to the string 'userprefs' instead of a decimal value, the required threashold value will be taken from spamassassin userprefs required_score instead of set to a static value. This allows a per-user based threshold value.
In d5954ce249, dhparam has been added
to the tls plugin. But a typo was made, misspelled "sp" as "self".
This commit corrects this typo.
Signed-off-by: Tom Li <biergaizi@member.fsf.org>
* Fix Can't call method 'notes' on unblessed reference in plugins/logging/file.
* Allow white space rather than just a single tab character in the badmailfromto configuration file.
Prevent the following error if we receive an invalid RCPT TO (eg <"relaytest%nmap.scanme.org">)
Can't call method "qp" on an undefined value at /usr/share/perl5/vendor_perl/Qpsmtpd.pm line 451.
/usr/bin/qpsmtpd-forkserver[17472]: command 'rcpt' failed unexpectedly
* Update data_post_headers documentation
We cannot reject at this stage, which is only there to alter headers.
Fix#258
* DMARC plugin: reject in data_post
Followup of #258: we cannot reject a connection during data_post_headers. So add a new hook in data_post to do the real rejection
* Support spf rejects when no DMARC policy is published
When using DMARC, you have to run sender_permitted_from first, and without rejecting anything. If a DMARC policy is published, then fine, the dmarc plugin will handle this. But if there's no DMARC policy at all, then we can decide solely on SPF to reject on not. This decision must be taken after dmarc runs, so, add a hook into post_data (dmarc is evaluated in post_data_headers). A new no_dmarc_policy argument is available and you can decide the level at wich you want to reject on SPF failures
* Typo
* Update data_post_headers documentation
We cannot reject at this stage, which is only there to alter headers.
Fix#258
* DMARC plugin: reject in data_post
Followup of #258: we cannot reject a connection during data_post_headers. So add a new hook in data_post to do the real rejection
* Use candidate_dirs to find the DB
* Update data_post_headers documentation
We cannot reject at this stage, which is only there to alter headers.
Fix#258
* DMARC plugin: reject in data_post
Followup of #258: we cannot reject a connection during data_post_headers. So add a new hook in data_post to do the real rejection
* Add the dmarc_reject note on the transaction
It's probably possible to have one valid email after an invalid one using the same connection (even if not common)
* Update data_post_headers documentation
We cannot reject at this stage, which is only there to alter headers.
Fix#258
* DMARC plugin: reject in data_post
Followup of #258: we cannot reject a connection during data_post_headers. So add a new hook in data_post to do the real rejection
* Add a note with dmarc_result
So other plugins can easily check DMARC status.
For example, a simple plugin can be added after DMARC when SPF hard failed, but no DMARC policy is published (so no rejection by the DMARC plugin).
With this note, we can easily check the result of SPF and DMARC and reject if the first is failed, and the second is none
* Update data_post_headers documentation
We cannot reject at this stage, which is only there to alter headers.
Fix#258
* DMARC plugin: reject in data_post
Followup of #258: we cannot reject a connection during data_post_headers. So add a new hook in data_post to do the real rejection
Because $pol->rue returns undef is there's no rua defined, an error is printed in the logs
FATAL PLUGIN ERROR [dmarc]: URI string is required! at /usr/share/perl5/vendor_perl/Mail/DMARC/PurePerl.pm line 295
When using the naughty plugin to defer rejection, we loose the name of the original plugin which caused the reject.
Especially when we parse the logterse plugin output to build graphs. With this addition, we now can get this information back
* Make spammy_tlds configurable
The hardcoded list of spammy tlds can't fit every needs. Makes this configurable through a config file.
You can now also raise the karma for tlds you want.
The default config provided keep the same behaviour as before.
* Update tlds' karma
The default behaviour (connection needs to have at least 3 or -3 to be considered
nice or naughty) is not always what we want, depending on the number of plugins
which adjust the karma. Lets make it configurable
Some users might need to enable the old SSLv3, or others might want to disable TLSv1. Lets make this configurable.
The default value is kept, but can be overriden in the tls_protocols config file
