Oops, I thought I was replying to the list, and only spotted
afterwards that I'd replied to personal mail.
This might be of wider interest...
---
> I don't have an answer to your question but I would like to know how
> you do selective callouts.
Almost entirely on the basis of a locally maintained .db of domains
where the procedure has been found efficacious, i.e with a line such
as
sender_domains = partial-dbm;CONFIG_DIR/callout_domains.db
in the relevant ACL.
What it comes down to is that if spam is seen getting through with
what appear to be faked envelope-senders (and I can't see any better
way of keeping it out), then I try a manual callout to the address in
question to see if callout would be effective. If the domain fails to
repudiate the address in question, or if it fails to repudiate a
random address, or if it takes 90 seconds before it responds at all,
or if it responds with 4xx unknown user (believe it or not, I've met a
number of MTAs which do that!) or similar, then it's not going to be
any use. Otherwise I could add the domain into the list (and re-make
the .db, of course).
Occasionally it's necessary to take domains out again because their
callout behaviour changed, e.g they start taking too long to respond,
or they won't respond at all after being asked a few times, suggestive
of some kind of rate-limit mechanism.
Our list isn't really of any public value: it's just assembled by
happenstance from the point of view of our own mail server (which
means I'm not offering to make its contents public in any way, sorry).
There are a few wildcard entries in there, usually of the form of
*.domain.example, occasionally *.sub.domain.example, but most of the
entries are individual FQDN entries.
[And I do have another ACL stanza which tries a callout on any
envelope-sender domain, when certain other conditions give rise to
suspicion: but these have proved troublesome, and I don't think we'll
be keeping them permanently.]
> Callouts can be useful for stopping spam with bogus from addresses
> but I would rather not waste time doing them when it's unnecessary.
As Chris Edwards already said (and I understand there are vociferous
discussions about it on SPAM-L), some domains on the receiving end of
this kind of faking are none too happy at having to handle the
overhead of continually repudiating fake addresses. So this needs to
be done with some care and selectivity, if it's done at all. In a
sense you may be trading a relatively expensive task i.e spam-rating
on your own system, for a relatively low-cost task i.e callout but
involving resources on a third-party's system. For massively faked
domains (hello, Suresh) the cumulative effect of too many victims
trying to validate addresses at the servers of an innocent third party
might become too much.
Definitely, all other feasible measures (dnsRBL blacklisting, local
blacklisting, bogus-HELO controls etc.), should be done first, and
callout left as late as possible.
[Well, looking at the problem from the other side, we repudiate large
numbers of null-envelope-sender transactions targetted at faked
addresses in our *own* domains; we don't of course know whether we're
doing this in response to callouts, or in response to attempts to
deliver non-delivery reports to us. At least we're playing our own
part in this game, is all that I'm getting at.]
The same mechanism can also be used, if you want, to punish sites
which respond 5xx to MAIL FROM:<> - if we add their domain to the
callouts list, then for so long as they do that, we'll refuse to
accept any mail with that envelope sender domain (exim treats the
callout as having permanently failed, just as if the callout MTA had
repudiated the tested sender address).
I will admit there's a number of pitfalls. If the callout MTA doesn't
respond for some reason, then we defer the transaction; spammers may
give up at that point, which is nice; but others will retry at the
usual intervals. If the reason the callout MTA didn't respond was that
it's busy, then the various retries aren't going to help! So you get
bipolar situations where a given domain sometimes responds
successfully to the callout at the first attempt, sometimes provokes a
long train of retries for half a day or more before answering. We had
(for example) to take hotmail and yahoo out of the normal callout
list, way back, because of this kind of effect. (N.B both of those
have behaved differently at different times.)
One way of cutting down on callout attempts is - if you know what the
genuine outbound MTAs are for a given domain, then you only try a
callout when the envelope-sender is presented from a *different* MTA.
However, some outbound MTAs don't seem to care whether their users are
presenting a valid sender address or not, so that can cut both ways.
Sorry, I've rambled on a bit there. Callouts are contentious and can
be troublesome. There are folks who think they're at least
discourteous, if not downright abusive. In the long term it's kind of
obvious that if the use of callout became widespread, spammers would
simply move over to faking real addresses, or faking addresses on
domains where callout doesn't work. But callouts still seem to be
keeping out a reasonable amount of spam for us, and we're playing our
own part as best we can to repudiate faked addresses in our own
domains. Hope that helps.
