Re: [Exim] Urgent problem: Blanket rejection problem on upgr…

Góra strony
Delete this message
Reply to this message
Autor: Nigel Metheringham
Data:  
CC: Exim Users
Temat: Re: [Exim] Urgent problem: Blanket rejection problem on upgrade to 4.31
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 - ]