Re: [Exim] callout suggestion

Top Page
Delete this message
Reply to this message
Author: David Woodhouse
Date:  
To: Chris Edwards
CC: exim-users
Subject: Re: [Exim] callout suggestion
On Mon, 2004-02-23 at 14:42 +0000, Chris Edwards wrote:
>    http://www.exim.org/pipermail/exim-users/Week-of-Mon-20030512/053733.html


Hmmm. The answer 'fix the documentation' was the wrong answer. Needs
asking again :)

> ooh - I'd never thought recipient verification callouts would be used for
> for mail from +relay_hosts (outgoing mail).


Actually I think I stopped doing this, because local MUAs can be fairly
crap at dealing with SMTP errors. As you said, we can hopefully trust
the return-path, so it's OK to just accept-and-bounce these.

> We use the facility (as Nigel described) on our gatekeeper MXs as a "cheat"
> to get the user db for some internal domains - to avoid sending bogus
> bounces to forged senders. This works well.


I do it for my backup MX boxen too -- you should be kind to the peanut
gallery when mentioning this in public and clearly state you should be
using defer_ok :)

That's why my backup MX started rejecting mail destined for my lists --
the primary rejected the callout because of the empty reverse-path and
hence the backup MX then rejected the mail.

I've jumped through hoops to avoid having the backups do recipient
verification for those addresses, and I dislike it immensely -- it
currently involves having a duplicate list of mailing list addresses,
distributed across the cluster.

If I start doing SRS on my own personal outgoing mail and rejecting
bounces to dwmw2@??? I'll have a similar problem.

> But in the case of +relay_hosts, surely you are quite entitled to send the
> local user a bounce as you (hopefully) already know the return-path is
> valid ?


Indeed.

> I'm just curious as to what situations recipient callouts are useful...


Mostly for backup MX then, but that's the case in which I've actually
_experienced_ problems due to the empty reverse-path in the callouts,
rather than just observing that they're possible.

--
dwmw2