Disable DNSBL checks for authenticated users

[hotstepper13]

Adding manitu dnsbl instead and remove spamchecking for authenticated users

[Udera]

👍

[rimas-kudelis]

I had a situation in the past where my server sent out spam because somebody's password wasn't strong enough or was leaked/hacked/sniffed AND SpamAssassin checks were disabled for authenticated users.

Which is why I think that checking for spam is a good idea even if the sender is an authenticated user, so I'm not fond of disabling it.

We could discuss this further if you like. In that case, I suggest to split this patch into two, because I certainly don't mind replacing the retired DNSBL with something else.

By the way, I can't resolve ix.dnsbl.manitu.net. Is this a public service? Does it have a homepage?

[Udera]

http://www.dnsbl.manitu.net/?language=en

I also prefer checking all mails by spamassassin. In most cases, you also handle mails of your webserver.

[hotstepper13]

In my case the Problem was a false positive for my own dial up ip. Here in Germany we use many dynamic ips which means our provider assign us a new ip each time we dial in again (regulary most providers have a 24 Hour forced reconnect). I am using the Provider Unitymedia and the network ranges for this provider are listed at spamhaus. So if I send a mail to my server it was rejected as the network of my provider was listed at spamhaus. That is the reason why I disabled the dnsbl checking for authenticated users. The patch doesnt disable spamassassin at all. Only the dnsbl checking should be skipped for authenticated users to prevent false positives.

[hotstepper13]

Additional info:
I installed also fail2ban in order to observe the mail logfiles. So if someone has 3 authentication errors within one hour he will "banned" by iptables for an hour. This works pretty well and reduce the "load" of the mail server at his have not to handle brute force requests. Luckily my server is not attractive enough to raise efforts (like using a whole botnet with multiple ips for brute forcing).

If you want, i could add installation documentation, too (just tell me if I should use the wiki or documentation within the project)

[rimas-kudelis]

@Udera: indeed, if this doesn't affect Spamassassin, then perhaps it's OK?

[Udera]

@hotstepper13 The exim-wiki gives a few samples how blacklist-checks can be combined with others to avoid such problems:
https://github.com/Exim/exim/wiki/Verification#sender-verify-failed-and-blacklisted

Blacklists are as well integrated in spamassassin (and you can also ad the ix-manitu-blacklist to it) so if we checked all incoming mails for spam this would be sufficient. Using a list as only rejecting criteria can cause false positives (like your authenticated users).

I see these two options:

• Use blacklist together with a second criteria (sender verify failed, or authenticated)
• Disable blacklist checking and refuse mails above certain spam-score (perhaps: + rDNS checks for non-authenticated users: Add reverse lookup #129)

[rimas-kudelis]

Can you reword this so that it doesn't sound like we're actually disabling spam checks here, but just DNSBL checks?

Also, I'm unsure if the comment above is even necessary, but even if you want it to stay, I don't think the second one should start with the word "Also".

[runout-at]

what about using policyd_weight instead?
config example: Acl policyd weight #153

[Udera]

Should we split this pull request? I think there are no doubts about disabling a non-existing blacklist and we have to put it in the next release.

Then let's open a new topic about the default behavior of vexim. Either we push such things in a vexim 2.3.1 or we directly move to vexim3.

[runout-at]

DNSBL config is not the main purpose of vexim but i like the idea of having the examples here.
Which DNSBLs are used should be a decision of the site admin.

We could have the example but should state something like: .."using specific and working DNSBLs is the responsibility of the admin. Things can change and a DNSBL could disappear and/or deliver positive responses on all domains."

[Udera]

DNSBL config is not the main purpose of vexim but i like the idea of having the examples here.
Which DNSBLs are used should be a decision of the site admin.

sure, but I would keep the current default settings. Comment new or alternative versions unless we decided that this is a much better default behavior for everybody (should then also be on some sort of release notes).

[Udera]

This authentication is something perhaps to improve.
The DNSBL-list needed to be updated for version 2.3, so I created a separate PR: #166
Changing milestone to 2.3.1

[Udera]

I put the changes into a new PR: #205

[Udera]

Authenticated users are now accepted regardless of the DNSBL status: #205
The old DNSBL was removed here: #166