Re: [Exim] Temporary defer on callouts

On Fri, 30 Jan 2004, Edgar Lovecraft wrote:

> I currently use the deny_ok in sender callout verification, that is not
> where the problem is. I am currently working on a better solution than
> the callouts (or atleast more selective callouts)

We use callouts primarily for domains where callouts have been checked
and proven to be efficacious. There are just too many domains where
any arbitrary localpart will pass the callout test (and only get
rejected at a later stage), making the effort of the callout
pointless. So we have a callout_domains.db that's looked up by the
relevant ACL clause, and we add to it manually as the situation
arises.

I also schedule callout there for some dubious domains which are
currently refusing bounces, so that they can deny themselves the
ability to send us mail. My idea here is that this will be
self-correcting: when they fix their problem, we'll stop refusing
their mail, without further maintenance effort on our part. Of course
there are more direct ways of refusing mail from domains that we are
more definite about wanting to refuse!

> as there are WAY too many 'legite' domains out there that do not
> accept the 'mail from: <>' command,

One could argue that there's no such thing as a legitimate domain
which refuses bounces as a general rule. By refusing bounces, they
put themselves over the border of what is legitimate. I'd claim,
though, that our practice of refusing (with appropriate explanation)
bounces *if* they appear to be bogus virus alerts (BVAs) is
admissible. We also rate bounces for spam, since some spammers try to
get their spam through camouflaged as a bounce, so this is another
possible cause for us rejecting a specific bounce (but obviously we
wouldn't reject a callout on that basis, since an incoming callout
never gets to the spam-rating stage).

> so I get alot of complaints from users about so-and-so not being
> able to send them email any more...

We get a modest number of complaints from senders whose mail is
blocked by us for various reasons, but this particular cause rarely
features. However, as I say, domains aren't usually added to our
callout_domainss list without administrator action (there are a few
wildcards in there, mostly ending in .kr or .cn). If we did it on a
blanket basis, I could well imagine that becoming a problem.

Incidentally, some domains never respond at all - in which case, the
callout mechanism would lead to mail attempts which have that domain
in the envelope sender being temp-failed indefinitely until they give
up: to keep the noise down, we have a manually-updated
unreachable_domains.db which results in those envelope-senders being
perm-failed with an appropriate diagnostic. There's an offline
maintenance script which runs now and again to verify whether the
unreachable domains are indeed still unreachable.

> I have also found that this problem has just gotte worse this week as
> even more silly admins seem to think that not accepting mail from: <> is
> a good way to stop the virus, or more likely all of the
> MailScanner/TrendMicro/NortonAV reject messages.

beware the quick-fix! Those BVAs are a pain in the neck, but there
has to be a better way to deal with them. Any chance of a DNSRBL
listing the senders of BVAs, I wonder?

all the best