* 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
The hack for outlook (replacing CR in X-Spam-Status header) assumes
that there is only a single occurance of CR. However, if spamassassin
adds some more spam status information X-Spam-Status might be several lines
long leading to multiple occurance of CR.
This fix changes the substitute to a global subsititute, replacing all
CRs in the X-SPam-Status header.
