On Thu, 23 Jan 2003, Giuliano Gavazzi wrote:
> At 1:51 +0000 2003/01/23, Alan J. Flavell wrote:
> >local blacklists first, then the DNS-based RBLs, and only if the mail
> >gets past those, and then only if the sender domain is in our list of
> >domains for which we've concluded that callbacks are a worthwhile
> >exercise, do we actually try that.
>
> aren't DNS-based RBLs quite expensive, even more than callbacks?
DNS lookups are, at worst, cached by the local DNS server, so they can
handle a cluster of spam attempts from the same source (which in our
experience seems to be quite a common pattern).
> Also, I just did a test, and the callback that failed on one
> connection was not repeated on another connection
Cacheing of callback results was introduced at 4.11 - see
ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/ChangeLogs/NewStuff-4.11
item 30. We're still using 4.10, sorry.
> So I think that one should streamline the check for callbacks, even
> if this means accepting a few spam emails.
There was a discussion thread about this from October 2002; on a
server of the modest size I'm dealing with, it's feasible to take a
manual decision whether to add an email domain to the local list of
callback domains (well, some of them are wildcarded); others on that
thread disagreed, but they were working on a very different scale.
> (But why do we accept
> callbacks when the old VRFY is considered "no go").
Well, a significant proportion of MTAs out there seem to respond along
the lines of "recipient is syntactically OK" to any random
(syntactically valid) recipient, making it pointless to attempt a
callback to those. That's kind-of functionally equivalent to refusing
to VRFY.
But as long as callback's doing a useful job, which can't entirely be
substituted by some other checks, I think it's worth using, at least
selectively, even if - as was obvious, if this discussion hadn't
reminded us of it - counterfeited addresses are throwing an extra load
onto innocent third parties.
