1792 requests/sec are too many from 32768 127.0.0.1,41617

Vernon Schryver vjs@calcite.rhyolite.com
Wed Jul 18 20:39:09 UTC 2007


> From: Chris Aseltine 

> > The only increase I've noticed in greylist-resistant spam that I've
> > noticed is in backscatter.  I wonder if you are using `dccd
> > -Gweak-body` or `dccm -GIPmask/xx` with too broad a netmask.
>
> Well, I'm using IPmask/16.  Are you saying I'm (potentially) getting the
> same exact spam from two different zombies in the same /16, separated by
> some amount of time, and so it counts as passing the embargo?

Yes.

I think IPmask/16 is too broad.  I'd stick with /24 or smallers.
IPmask/xx is intended to treat a cluster of cooperating mail systems
as if they were a single system.  Many larger ISPs shuffle outgoing
mail messages among several mail systems.  Many make a first try from
one IP address and retransmissions from other IP addresses.  Without
IPmask/xx covering all of them, the initial transmissions from the first
address will always embargoed.


> > Unless you are using a DNS blacklist that is purely automatic, an
> > embargo less than several hours or a day sounds optimistic.
>
> I thought most DNS blocklists were automatic?  At least the ones that are
> powered by spamtraps?

The CBL possibly asside, I think that is mistaken for major blacklists.
For some major DNS blacklists including the SBL, I know that is
mistaken.  I'm fairly certain it is wrong about the PBL.

I prefer the honest and straightforward word "blacklist" instead
of the disingenuous neologism "blocklist."  They are "blacklists"
no matter what you call them.  Calling them something else offers
no protection against complaints or lawsuits.  But years ago when
I worked nights sweeping floors and scrubbing toilets, I also didn't
like "custodial engineer."

There are many kinds of "spam trap."  At one extreme are spam traps
that have never been used for real mail and are unlikely be hit by
typographical errors.  At the other extreme are addresses that were
used but have been retired for many months or even years.  Automatically
blacklisting SMTP clients (mail senders) that hit one of the latter
type can cause false positives.  Automatic blacklisting using hits on
the first type strikes me as dangerous.  How can you be certain that
your spam trap is not one keystroke away from a legitimate address?
Depending on how you seed your traps, how can you be certain that a
silly user has not read your HTML and sent legitimate mail to a hidden
trap instead of the contact address?


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.