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.
The callout cache for the second situation will need more aggressive
pruning otherwise it may take over the machine :-)
Nigel.
--
[ Nigel Metheringham Nigel.Metheringham@??? ]
[ - Comments in this message are my own and not ITO opinion/policy - ]
