On Mon, 2003-12-15 at 14:11 +0000, Philip Hazel wrote:
> No. The worry was again the causing of loops. Yes, I know that if all
> MTAs that do callouts are careful, loops shouldn't happen. But I was
> paranoid...
So was I.... and then my MX backups stopped accepting mail for my
mailman lists :)
I've worked around it now by not doing recipient callouts for the lists,
but that involves duplicating information about which addresses are
lists to all the MX backups (although I'm playing with DNS lookups for
this kind of thing, which gets shadowed nicely)
I'm not sure I can imagine a situation where callout loops will happen,
unless when the mail itself is going to loop indefinitely anyway.
Although I suppose the Received: headers stop that in the end... is
there anything which prevents Exim from doing two concurrent callouts
for verifying the _same_ address? If so, it should be safe to allow the
ACL to specify that the original address is to be used, shouldn't it?
In fact, if we use postmaster@$primary_hostname as the source for
callouts, if by some change that _does_ get back to us, we'd never do a
callout for that address anyway, would we?
Could we add 'expanded source= option for recipient verification' to the
WishList, please? I certainly wouldn't advocate doing it for sender
verification, but it should be fairly safe for recipient verification,
even if we don't make it the default.
Alternatively, it would suffice if I could test the rejection message
received by the callout...
# Deny unknown recipient at relay domain, with callout but accepting
# temporary failures (else backup MX is pointless).
deny domains = +relay_domains
!verify = recipient/defer_ok/callout=20s,random,defer_ok
!condition = ${if match{$callout_rcpt_response}{^.*should not receive bounces} {1}
message = Unknown recipient at target domain
--
dwmw2
