* 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
* 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.
calling it as such. It doesn't resolve#199 but it does help there.
I'm not sure initializing Qpsmtpd::transaction as {} is a brilliant idea, but I haven't a better solution for that yet.
don't load plugins twice.
Not exactly sure where that feature crept in some time ago. It was suppressed by checking to see if a queue plugin was already registered, and then bailing out on subsequent register_hook runs. I noticed it in testing, b/c I didn't have a queue plugin loaded. This removes the duplicate calls to register_hook.
* adds caching of the AUTH methods. You can't add new plugins or register new
hooks w/o restarting QP, so cache the list and avoid having to generate it on every connection.
* other PBP changes (early exits, less indention, fewer unnecessary parens, etc.)
