* 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
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.
