>On 29 Feb 2004, Thanos Massias wrote:
>> On Sat, 28 Feb 2004 16:03:21 +0800, Christopher Chan <***@graffiti.net>
>> wrote :
>> > JCB said:
>> > >
>> > > probably guess what it is from earlier discussions on this list, you'd
>> > > need to patch qmail-smtpd (it's not hard, I've done it myself), and
>> > > make some minor adjustments to your system configuration.
>> Just a guess but...
>This particular idea (if it's the one JCB is talking about) has been
>floating around for a while. However, it's not widely deployed - from
>our January SMTP survey, 2479 of 59804 servers (4.1%) use it.
So it's still in the "probably worth deploying" phase, not quite yet
in the "nearly everybody's doing it, so it's no longer really worth
doing anymore yet" phase, of the typical anti-UBM-measure life cycle.
That's good to know!
>addition, the more recent spam vectors handle it just fine - the SMTP
>engine in MyDoom, for instance, has no problems in this respect.
Makes sense; as I said, a fair amount of spam and vermin gets past
that point of the SMTP conversation on my system.
It just surprised the heck out of me to see how *much* UBM got knocked
down by this simple tactic, and how effectively it "usurped" the roles
of certain other less-savory anti-UBM tactics I'd already deployed.
(Less "savory" because they use things like the HELO/EHLO name,
spamtrap envelope recipients, and message content to filter out UBM;
this tactic doesn't do any filtering along those lines, so it really
can't have any "false positives" from conforming-client, envelope, or
message-content points of view, as can these other tactics.)
I had high hopes pinned on *another* anti-UBM measure I thought might
knock down a fair %; though it's only in "detect and report" mode,
it's clear that, though stunningly inexpensive to deploy, it won't
help nearly as much as I'd hoped. So the one that prompted me to
start this subthread really took me by surprise; didn't even notice it
was having such an effect until I began to wonder why my incoming
spam/vermin rate had dropped so much, and looked more closely at my
>It has the upside of being easy to bring in to play. If you don't
>mind a little performance hit, it can be done [...]
>Another thing that could be tried [...]
>From a performance/resources point of view: given a site that is
presently using tcpserver to look up TCPREMOTEHOST, possibly in
"paranoid" mode, perhaps TCPREMOTEINFO as well, perhaps various RBLs
too, and therefore handing these connections off to qmail-smtpd only
*after* these lookups complete...
...doesn't it make sense to delay looking up that information until
*after* certain anti-UBM measures, that are useful early on in the
conversation and that might convince UBM software to simply give up,
have allowed only a subset of incoming SMTP connections through?
That would, in *today's* environment, based on my *own* (admittedly
narrow) experience with UBM, substantially reduce the load on my DNS
subsystem. (Which isn't actually an issue for me; I haven't actually
told tcpserver to stop looking up TCPREMOTEHOST and TCPREMOTEINFO
(At least, *I* really don't care what the reverse-DNS or RBL info for
an incoming SMTP connection might be if it never reaches the point of
actually trying to deliver a message. It might be "fun" to have for
logging or curiosity purposes; but for a site that's already
overloaded just accepting incoming SMTP connections -- and I've
personally observed several *valid* sites in that boat recently --
nobody who could use that info probably cares enough to see it.)
So, if a larger % of incoming connections can be knocked down, via the
tactic I'm talking about, *without* first doing comparatively
expensive lookups, than can be knocked down via the lookups combined
with whatever internal lookups based on TCPREMOTEHOST and
TCPREMOTEINFO might be done (e.g. RBL-style lookups on host names),
isn't that a straightforward way to *improve* performance?
I think so. I think it might actually *improve* performance of an MTA
under sufficiently aggressive assault by UBM warez. Which is why I
brought it up in the first place.
That's why I think it's better deployed as an improved, more flexible
qmail-smtpd, than hacks via shell scripts. (That, plus the sheer,
mind-numbing inelegance of doing it via a shell script, e.g. via a
tcpserver option! I couldn't *make* myself even *experiment* with the
tactic using that approach. Better to teach qmail-smtpd to just
assume, based on an environment variable, that the whole issue has
already been taken care of *before* it got the connection; but I chose
the other approach of having it handle the whole issue itself. With
vanilla qmail-smtpd, employing the tactic via a shell script means
either using a proper wrapper for the session, not just a hand-off a
la the exec command, or risking deploying a nonconformant SMTP server
as seen by the client.)
Improving qmail-smtpd to make it more flexible would mean having it
handling more stuff than it ideally should, e.g. looking up
TCPREMOTEHOST, TCPREMOTEINFO, and doing RBL-style lookups as directed,
but later on in the SMTP session, when various configurations are
called for, after some illegitimate clients might have already given
up and disconnected, saving qmail-smtpd the trouble. (This is
probably what replacements like qpsmtpd and mailfront do already, at
Regardless, another advantage of the basic tactic under discussion:
once the equation changes -- once the evilbotware adapts, on a
sufficiently widespread basis, to be invulnerable to this tactic such
that the tactic isn't worth even its tiny added expense -- then,
unlike many other anti-UBM tactics, it's *trivial* to stop using it.
There are simply *no* support or compatibility issues involved when it
comes to this "undeploying" particular tactic, once it's been
deployed. (I know there's got to be a real word for "undeploying", I
just can't deploy it right now.)
James Craig Burley