Am 04.03.2015 um 17:06 schrieb Jochen Bern:
On 03/04/2015 05:03 AM, Earl Killian wrote:
I would like to reiterate Reindl Harald's point above, since subsequent discussion has gotten away from it. If Dovecot had DNS RBL support similar to Postfix, I think quite a few people would use it, and thereby defeat the scanners far more effectively than any other method. It is good that other people are suggesting things that will work today, but in terms of what new feature would be the best solution, I can't think of one better than a DNS RBL.
I've *seen* mailservers after an external DNSBL configured into them became defunct or unreachable, and "better", much less "the best solution", is not how *I* would rank the result in comparison to local rate limiting. (Note that, unlike in the case of spam and SMTP, allowing a couple POP/IMAP connection attempts until the limit strikes is unlikely to become visible to the legit userbase.)
Which is not to say that such a feature should not be implemented - after all, Jim said that he compiled the 45k list *himself*, so it would be a *locally administered* DNSBL for him.
surely - and *that* was my whole point, nobody talked about using spamhaus or DUL RBL's on a IMAP/POP3
my feature request last year was *because i have* already a rbldnsd which is used in postfix and on webserver with mod_security and i find it strange that i can't stop a dictionary attack faced on SMTP to continue on POP3/IMAP after locked out from postfix without write firewall rules
the whole point of a *locally administered* RBL is that you don't need to care about hown many mailservers you have and where they are nor need you to open security holes between them for sharing data
On 03/03/2015 10:43 PM, Reindl Harald wrote:
the problem is the "in a secure way"
that's not really possible when you mangle firewall rules which implies root permissions - as RBL request is just a DNS request which don't need *any* permissions on the machine which does the request
the other problem is mangle firewall rules in context of existing infrastructures is error prone - you may interfere existing rulesets
- it's a bad idea to start with
That's a lot of smoke you're blowing at a firewall that hasn't been specified beyond "it's *not* iptables".
FWIW, *if* it were iptables, something along the lines of "-d myserver --dport 993 --state NEW -j (NF)QUEUE" would happily pass *only* the incoming IMAPS connections to a decision-maker running in userspace.