On Mon, 2004-04-05 at 12:37, Bruce Richardson wrote:
> On Mon, Apr 05, 2004 at 01:02:52PM +0200, Tamas TEVESZ wrote:
> > On Mon, 5 Apr 2004, Bruce Richardson wrote:
> >
> > > > a) Exim is now using the original sender address rather than <>
> > > > to do callouts
> >
> > > the RCPT stage, because that's when the callout is happening. The
> > > problem is entirely point a). Which is a big problem.
> >
> > because? that's how it will be sent on to the internal host, afterall.
>
> It's a bloody big problem because Exim doesn't detect a rejection of the
> MAIL verb, It treats a rejection of the MAIL verb as a rejection of the
> RCPT verb and then, presumably because this change was unitentional,
> WRONGLY REJECTS EVERY SINGLE RECIPIENT FOR THAT DOMAIN, based on
> incorrect cached callout data. Are you quite clear about that, now?
Normally if recipient callout verification fails then that (single)
recipient ought to be cached for negative responses to further delivery
attempts.
In this case verification of the sender is failing during recipient
callout verification. This is a little interesting because presumably
the sender should already have been callout verified, so you wonder on
what basis the rejecting is taking place on. However the fact that this
sender rejecting is causing the whole domain (ie any
address@???) verification to be negatively cached is very very
odd.
The short term workround is to turn off caching of results.
Longer term I guess that you can do the following:-
* as an urgent minimum, do not make sender led responses to
callout verification hit the cached results for recipients.
* negative cache (for an appropriate period) failing sender
addresses to that domain (actual local_part within that domain
is irrelevant here).
* positive/negative cache (appropriately) sender/recipient
couplets.
* Maybe have a config option that allows you to state that
recipient verification is not affected by the sender address, OR
to allow specific sender part to be used.
--
[ Nigel Metheringham Nigel.Metheringham@??? ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
