Re: [Exim] callbacks and <>

On Tue, 9 Dec 2003, Bruce Cornett wrote:

> I have had little success in making the RFC argument. They understand the
> RBLs, but the concept of an RFC doesn't penetrate (which makes sense in
> context - most of our clients are US Based; we seem to favor unilateral
> action like the RBLs and we just won't stand for the likes of international
> consensus:(.

"you might say that - we couldn't possibly comment..." - sorry :-}

> So yesterday morning I turned sender_verify off.

Just to be clear about this, if I may? I see three possibilities: no
sender_verify; sender_verify without callout (i.e it basically
checks-out the domain lookup, but without actually calling it); and
sender_verify with callout. (There are some other twiddly bits, but
this is the chief issue, I think).

From the context of your problem, you were evidently doing callout
before.

> That action permitted about 2000 additional mails into our system in
> the last 24 hours and we're a small outfit.

By "that action": did you switch off callout, or did you switch off
sender_verify altogether. That was what was unclear to me.

FWIW, on our mailer we use sender_verify by default, but without
callout: we use callout only for selected domains where callout has
been checked and found to be useful (along with some wildcarded
domains from which we suppose productive mail is conceivable but
highly improbable, so we feel we can take the risk of a "blind"
callout). (And along with a few nuisance senders who reject bounces,
which it amuses me to block by deliberately enabling callout and
letting them block themselves...)

Just in the last few weeks, however, there has been a massive outbreak
of some spamming tool or ratware which counterfeits sender addresses
with a good domain after the "@", and a local part which is made up of
a likely-looking user name plus a two-letter suffix (sometimes with
underscore, sometimes not). We reject considerable numbers of these
for various reasons, and I think I've mentioned this pattern in this
forum before. I'm sure that others are seeing it too.

As you can see, for these it would be little use attempting a
sender_verify based on domain only, since these counterfeited
addresses generally contain good domain names.

Lots of these get rejected by us because of the IP from which they are
being offered (dynamic IPs, adsl and the like). Evidently the
original spams are launched through some kind of wormhole that has
been found (or created - virus?) in hosts that really have no business
to be sending direct-to-MX mail.

OK, one thing is clear: using RBLs is a potential problem - trusting
one's mail acceptance to some third-party RBLs over which one has no
direct influence and with which one has no contractual relationship,
and I imagine that would be considered inappropriate in a "commercial"
situation. But I have to say it's been a life saver to us (with
careful selection of RBLs and ongoing adjustment, for sure...)

By the way, in relation to the spamming modus operandi mentioned
above, we also reject huge numbers of non-delivery reports for such
counterfeited user names in our own domains. Well: either these are
non-delivery reports, or they are callouts to us - we can't be sure
which: since we reject them as unknown user at the RCPT stage, we have
no idea whether they would come with a non-delivery report payload if
they were given the chance. (We can't very well defer the RCPT checks
until end of DATA, because that would defeat the benefit of callout!).

Excuse me if I'm stating the bleeding obvious, but no single defence
measure is effective. Best results are achieved by a graded response
based on several factors, including DNSrbls, validity checks etc. as
well as content rating and ("pace" certain contributors) maybe also
callouts.

As long as some commercial mail software produces blatantly invalid
constructs and behaviours, they really mustn't be surprised when their
users experience difficulties sending mail! But I sympathise with
your predicament when they assert "everyone else accepts our mail" -
translation "everyone else swallows our broken crap, and heaven knows
what else they swallow" - to tell that story in full, we might maybe
begin with you know what...

All the best