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