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.

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to