On 2011-08-12 at 10:43 +0100, Christian Gregoire wrote:
> I bumped into this with a client of mine and now that he has removed the type 99
> filtering on his firewall, everything's smooth. But is there a way to specify
> some sort of timeout in an ACL ? defer_ok ? delay ? Unfortunatelly I can't
> easily do testing on my production mail platform.
Not really. Unfortunately, libspf2 doesn't provide a timeout mechanism,
so we would need to wrap the library calls in timeouts manually.
However, the abstraction would make this a "SPF result or SPF timeout"
expiry and the Exim code is in no position to timeout just the SPF
RR-type lookups, while letting the TXT RR-type lookups succeed.
If the libspf2 maintainers add a mechanism by which applications can
control the timeouts, we can add hooks to use it, certainly.
Really, there are two cases which are affected by broken DNS firewalls,
with three situations where you might be involved:
* you're checking SPF and your own firewall is broken
=> motive to fix firewall
* you're sending mail and your firewall is broken
=> some remote receivers reject your mail because of your broken
setup
=> motive to fix firewall
* you're checking SPF and occasionally it breaks for remote senders
=> let them know it's their fault
So this also seems like a self-correcting problem, as the entities
most affected are also the entities in the best position to repair the
broken setup.
None of which is a reason to not update Exim's SPF support to make life
easier for the mail-admin; but at present, we appear to have no
mechanism to do so.
I don't have time to get involved in chasing down inter-project liaison
work right now; sorry.
(Alternative scenario: my skim of the spf2 header files was too brief
and I've missed an API function call; if someone points me at what I'm
missing, that's another issue).
-Phil
