North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Spam filtering bcps [was Re: Open Letter to D-Link abouttheir NTP vandalism]

  • From: Matthew Black
  • Date: Thu Apr 13 11:32:43 2006

On Wed, 12 Apr 2006 18:56:44 -0700 (PDT)
 "Steve Thomas" <[email protected]> wrote:

How does one properly report delivery failure to a guerrilla spammer?
If you accept the message, you can presumably deliver it. In this day and
age, anyone accepting mail for a domain without first checking the RCPT TO
- even (especially?) on a backup MX - should have their head examined. In
the event that the RCPT TO is valid but the message truly can't be
delivered for some other reason,
In this day and age it is not always possible to check for valid
addresses at a border SMTP gateway. Sites have multiple legacy
systems which are not very interoperable. Some e-mail gateways
are incapable of scanning messages in-line. How does that make
the gateway junk or the system administrator an idiot or

you should bounce the message and fix the problem.
This is advocating collateral damage because nearly all spam
and viruses have return paths which falsely implicate innocent
victims (i.e., blowback). Users don't want it delivered or dropped
in their junk folder; most wouldn't know what to do with a junk

E-mail systems require investments in the 100s of thousands of
dollars, not some Windows PC running Linux. The largest part of
the cost equation is personnel and training, not hardware.

Large organizations like our shy away from open source software
in many situations NOT because it's open source. We opt for
commercial solutions so employees, like me, can take vacation
and know that other employees can handle problems and let me
enjoy my vacation without carrying a pager (unless you think
it's cool to be tethered to your job 24/7 with a Blackberry).

Dogmatic adherence to a literal reading of every RFC is
impractical. When my organization decided to drop BrightMail
postively-identified spam, we accepted a FP rate of less than
one in a million as a good thing, fully aware that this violated
RFC 821.

I used to love sendmail but recommended our organization drop it.
Sendmail's queue processing algorithm was (is?) hopelessly broken
and delayed e-mail for hours or just discarded it after five days
because sendmail couldn't properly prioritize the queue.

With our IronPort C60 gateway, almost all e-mail is processed
sub-second, users don't see postiviely-identified spam, and
viruses and phishing attempts are a thing of the past. Should
I no longer be able to perform my duties, for whatever reason,
our e-mail system will continue running and someone else can
take on my responsibilities with a tiny learning curve. No
worries about whether SpamAssassin got it's update. No worries
about whether ClamAV will be running next month. No worries
about system outages during complicated open-source software
upgrades, even for a few minutes. Unless you feel those are OK.

Ask yourself this question: can your organization survive a loss
of its entire technical staff? Would new employees be able to
manage your systems or would chaos result?

matthew black
california state university, long beach