Phil Pennock wrote:
> I agree strongly.
>
> Often, what is done with dnsdb can later be done better with new Exim
> features, but as a general tool to let the administrator get on and get
> the work done, I find dnsdb invaluable. I'm fairly sure that several of
> my posts to the list have assumed the presence of dnsdb without stating
> the assumption as I tend to forget that it's not present by default. In
> particular, I believe that some of my forany/forall examples use this.
>
> At the moment, the only live example in my real configs is this:
> ----------------------------8< cut here >8------------------------------
> # We don't filter on SPF in the normal case as it breaks forwarding. However,
> # if the sender domain claims that it never sends mail, then there's nothing
> # legitimate to have been forwarded, so we can drop that at least. Some people
> # are polite and note when they don't send email (eg, globnix.com).
> # Thanks to Mike Cardwell for the nudge to actually implement the check and for
> # the lookup which avoids an experimental-Exim dependency.
> deny condition = ${if eq{${lookup dnsdb{defer_never,txt=$sender_address_domain}}}{v=spf1 -all}}
> message = SPF records for $sender_address_domain explicitly state this domain should never send email
> ----------------------------8< cut here >8------------------------------
>
> (globnix.com being mine). I value having a test which is small and
> simple, avoids linking in a bunch of additional bloat which I'll likely
> never use and find the flexibility of dnsdb here to be of great use in
> implementing the only subset of the SPF functionality which I actually
> use. The flexibility of dnsdb greatly exceeds its cost.
>
> I just checked my logs for what this rule is catching and was pleasantly
> surprised. Thanks, Mike. :)
Cool. I remember posting about that, but wasn't sure if anyone actually
picked it up and used it. Good to see it's working for someone else.
--
Mike Cardwell
(
https://secure.grepular.com/) (
http://perlcv.com/)
