--- Original Message ---
From: Nigel Metheringham <Nigel.Metheringham@???>
Sent: Tue, 06 Apr 2004 17:32:51 +0100
To: Exim Users <exim-users@???>
Subject: Re: [Exim] Recipient callout problem
> On Tue, 2004-04-06 at 17:10, gARetH baBB wrote:
> > On Tue, 6 Apr 2004, Bruce Richardson wrote:
> >
> > > I brought this up on the list yesterday. It seems that the recipient
> > > callout logic was changed to use the original sender address and not <>.
> >
> > Hmmm, I can see why this might be useful - but personally I would prefer
> > if the old way could be flagged, and additionally in a similar way to what
> > "random" does now be able to tell the thing to start the verify with a <>
> > call and if that fails then to cache fail for the receipient as a whole -
> > otherwise the recipient callout cache is going to be 99% useless as it has
> > to callout for a billion different spam senders all the same receipient.
>
> There are 2 possible uses for recipient callout verification:-
> * Does this recipient exist? - sender is basically irrelevant,
> result can be cached keyed on the recipient only. However this
> requires some knowledge of the recipient site's policies (ie
> will sender=<> work - there are valid cases where it may not)
> * Can this message (with this sender & recipient) be delivered? -
> sender is very relevant, caching needs to be based on
> sender/recipient tuple. This will work correctly whatever the
> recipient site policies, but will hit the recipient site with
> many more queries due to lack of caching. You could, of course,
> negatively cache senders that are rejected at MAIL FROM: stage,
> but since good practice is to save sender verification until
> later thats going to be very ineffective.
Seems like a pretty easy thing to make an option to make everybody happy. If the default was to use a blank sender for recipient callouts, then add an option like 'tuple' or something that would use the new 4.31 method, you'd get the best of both worlds. One could just use different ACL's for whichever bits you wanted to use with whichever hosts.
I suppose, if somebody wanted to be extremely clever, they could analyze the callout cache to determine if a particular recipient was picky in what it received, then it could intelligently denote a particular domain/receiving host as 'tuple' or not. (might need more than 24 hours of data for that, though, but it'd be swank)
Kelley Reynolds
