[100907] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: unwise filtering policy from cox.net

daemon@ATHENA.MIT.EDU (Rich Kulawiec)
Wed Nov 21 10:07:41 2007

Date: Wed, 21 Nov 2007 10:04:24 -0500
From: Rich Kulawiec <rsk@gsp.org>
To: nanog@merit.edu
In-Reply-To: <20071120.225142.15106.0@webmail30.vgs.untd.com>
Errors-To: owner-nanog@merit.edu


On Wed, Nov 21, 2007 at 06:51:42AM +0000, Paul Ferguson wrote:
> Sure, it's an "unfortunate limitation", but I hardly think it's
> an issue to hand-wave about and say "oh, well".
> 
> Suggestions?

There are numerous techniques available for addressing this problem.
Which one(s) to use depends on the site's mail architecture, so I'm
not going to try to enumerate them all -- only to give a few examples.

Example 1: exempt abuse@ address from all anti-* processing; just deliver
it.  All the MTA's I've worked with provide features to support this;
it's also sometimes necessary to make that exemption elsewhere (e.g.,
in programs called invoked as milters).  Oh, and don't greylist it either.

Example 2: if using a multi-tier architecture (increasingly a good
idea, as it insulates internal traffic from the beating often inflicted
by external traffic) then re-route abuse@ mail to its own dedicated system
(using a mechanism like the sendmail virtual user table or equivalent).
Make that system something relatively impervious, and choose hardware
that can be replaced quickly at low cost.  (My suggestion: OpenBSD
on a Sparc Ultra 2, and use mutt as the mail client.  Keep a couple
of spares in the basement, they're dirt-cheap.)

---Rsk

home help back first fref pref prev next nref lref last post