On Tue, 2010-04-27 at 16:13 +0100, Peter Bowyer wrote:
>
> This case is a little more complicated - the OP has recipient
> verification turned on, and the routers are called after a RCPT to
> determine if a recipient is valid.
>
> What actually is determined is that a recipient is routeable - in this
> case, the 'invalid' recipient is, because it meets the conditions of a
> router. The fact that the result of its routing would lead to an NDR
> due to the 'fail' redirection isn't relevant - the redirection isn't
> processed.
Um, that's not true. If recipient verification is tried, it _will_
handle a redirect to :fail: in a router. For example...
220-bombadil.infradead.org ESMTP Exim 4.69 Tue, 27 Apr 2010 15:57:13 +0000
220 Be gentle with me
helo me
250 bombadil.infradead.org Hello macbook.infradead.org [2001:8b0:10b:1:216:eaff:fe05:bbb8]
mail from:<>
250 OK
rcpt to:<linux-mtd@???>
550 Lists do not send messages and should not receive bounces
quit
221 bombadil.infradead.org closing connection
... is implemented by a router:
mailman_bogus_bounces:
driver = redirect
senders = :
domains = +mailman_mx_domains
condition = ${if match_domain{$domain}{@mx_any}{1}}
local_parts = lsearch;CLUSTER/mailman/$domain
allow_fail
data = :fail: Lists do not send messages and should not receive bounces
> The two suggestions to deal with this situation in an ACL are good.
Personally, I dislike that suggestion; I think it's bad advice.
I prefer to have things _consistent_, so if a message manages to bypass
certain aspects of the ACL (by local submission, SMTP AUTH, etc.), it
still gets the same results. Implementing such policies in routers helps
me to achieve that.
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@??? Intel Corporation
