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
