On 7/18/2011 1:47 PM, Steve Fatula wrote: > Having read quite a few of the messages in this list about bounces, I really > didn't find any (though they may be there) related to preventing bounces for > resource limits, and other unpredictable and strange occurrences. That is my > question, NOT bad recipient, etc. Yes, I know bounces and rejects are totally > different.
The problem with bounces is not bounces per se, but rather bounces that go to the wrong party -- someone who isn't the sender. My opinion is if you correctly reject -- not bounce -- spam/virus/bad recipient email, that takes care of 95%+ of the problem bounces, and is a good practice minimum standard. It would be bad practice to eliminate bounces entirely; they exist for a good reason. Beyond the basics: - bad config bounces. Hopefully these are rare. I suggest concentrate on eliminating the errors, and don't bother trying to eliminate the bounce. If spam/virus/bad recipient mail is handled correctly, most of these should be legit mail, and the sender must be notified his mail wasn't delivered. - over quota and other resource bounces. Again, these should mostly be legit senders that should be notified if their mail isn't delivered. If you can get your backend to report error conditions during SMTP, it's worth doing. If your backend can't support this without major surgery, probably not worth worrying about until next time you upgrade. - Spoofed Delivered-to:. AFAIK this has never been a major problem, and is a useful feature to detect mail loops. If it becomes a problem, you can use header_checks to IGNORE Delivered-to (will let a loop run until too many hops are in the Received: headers, or until something melts if a hop removes Received: headers) or use header_checks DISCARD to just throw them away (not good if there really is a loop -- you want to examine the mail to fix it). -- Noel Jones
