[exim-dev] [Bug 2631] Option to restrict dnslists to specifi…

Pàgina inicial
Delete this message
Reply to this message
Autor: admin
Data:  
A: exim-dev
Assumpte: [exim-dev] [Bug 2631] Option to restrict dnslists to specific networks and log a warning if they return IP addresses outside this range
https://bugs.exim.org/show_bug.cgi?id=2631

--- Comment #2 from Simon Arlott <bugzilla.exim.simon@???> ---
(In reply to Jeremy Harris from comment #1)
> It's possible to use "!&127.255.255.0" which does take out 255.0/8.


This just isn't practical. I adjust the dnslists by local part so there's a lot
of additional complexity in doing this, not to mention the bitmask calculations
involved in making sure that it does what it's intended to do.

A way to define dnslists by a short name ("begin dnslists") would make it
easier
to configure them with multiple zones, inclusion/exclusion masks on separate
config lines and display names for the zones to hide API keys. That's probably
the topic of another wishlist entry but it could also be used to specify
address
ranges that are errors (!127.0.0.0/8) or warnings (127.255.255.0/24).

> Is there sufficient agreement among dnsbl operators to choose something as a
> new default for filtering?


At a minimum, 127.0.0.0/8.

> But Spamhaus also returns values in 127.255.255.0/24 to indicate non-match
> internal error cases. Should we care for logging, or leave the checking of
> the returned value/s to the sysadmin?


I would just add that range to the list of disallowed addresses in my
config because no other dnslist is using them.

> RFC 6471 says:
> - "most" ip-based dbsbls support queries for addrs in 127.0.0.0/24 (often
> 127.0.0.2)
> to test operational status
> - name-based dnsbls RECOMMENDED to support queries for "test" for operational
> status; and a query for "INVALID" getting a positive response should be
> taken as
> indication of non-function


It could be beneficial for Exim to do this periodically but I'm more concerned
with lists that start returning wildcard non-dnslist responses.

> - responses outside 127.0.0.0/24 should be taken as indication of
> non-function


There are lists where this isn't true.

--
You are receiving this mail because:
You are on the CC list for the bug.