To manage your outgoing traffic, your policies should explicitly define what kinds of email traffic are acceptable on your network and email relays. It is important to make a best effort to not become the weakest link in the chain, or in this particular case, a point of origin or relay for SPAM, worms, or other types of malware. Some specific configurations can make a spammer's life easy, and we'll discuss those in upcoming sections.
An effort to standardize bounce messages was made with the commonly used SMTP extension DSN (Delivery Status Notifications, RFC 1891). A DSN message is not limited to bounces; you can also use it for positive acknowledgment of any email delivery. Even though it's a widely accepted standard, it's not part of the SMTP specification (being an extension), and for this reason, some SMTP implementations use different formats for bounce messages.
The Qmail software is an exception in the MTA world because it never sends errors about invalid recipients over SMTP; it always delays them with a bounce. Also, Qmail doesn't support DSN but has its own bounce format (QSBMF).
Apart from being an annoyance and a policy problem for your MTA (not to mention the receiving side), messages that are infected with viruses or malware could pose a serious threat to your organization's credibility if the bounces contain the full body of the original message. The bounce message, sent from your MTA with your domain address as sender, would retain the malicious content that would be delivered to the originally spoofed address (which is external to your organization), effectively making you look like a malicious sender.
Of course, keeping only headers in the bounce has the obvious effect of saving bandwidth and a fair amount too if you consider the amount of unsolicited traffic that you are likely to bounce. In Sendmail you can retain only headers in the bounce message without the full body by adding nobodyreturn to your privacy flags:
In Postfix you'd have to set bounce_size_limit to limit the number of bytes to keep from the original message body.
If DSN is supported, you might also want to disable delivery status reports for successful messages (i.e., receipts of successful DSN) in order to prevent information leaking out about your local delivery process:
Was this article helpful?