Re: [exim] a large number of domains fronted by Exim are ref…

/ by Oliver Egginger or perhaps someone else
> It's advisable to do sender callouts with a null-reverse-path.
> At the moment we do sender callouts and reject every message which can't
> be verified by a callout. But by reading this thread I arrive at the
> conclusion that I'll better disable all denies which are based on sender
> callouts.

I would continue to reject all mail for callouts that used <>. They
send mail so they should be able to accept bounces/<>. The main
argument here is that a valid reason to reject all <> is for
mailboxes/domains that don't send mail -- so when your callout fails
and you reject the message its all good. For Recipient callouts, if
they don't accept <> then that would be a problem. Meanwhile, if the
senders do have a broken configuration and indiscrimently reject all
<>, then it's ok to reject them as they're probably idiots and you
don't want to accept responsibility for mail that could potentially
bounce and that you don't want to be stuck with.

I feel all callouts should use <> and that responses should be
deciphered finding "User unknown" etc, as hard as that may be. Wait,
I suppose recipient callouts could use the sender address, and the
error messages could be proxied back to the initiating session. I'm
not sure how sophisticated callouts are as I've never examined them
closely.

I would have thought someone would have mentioned callouts sooner.
They seem to be an excellent example of how <> senders can be used (to
avoid loops and such) and why rejecting <> could be detrimental.
Actually, I suppose if blocking <> is implemented in moderation for
accounts that don't send mail, alias etc, then that could help
re-enforce callouts.