IP drop list

[Reindl Harald]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://dovecot.org/pipermail/dovecot/attachments/20150304/6581b227/attachment.sig>