|
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]
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 incompetent? 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 folder. 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
|