Bounces of spam messages
Joe-jobor blow back spam are terms for the following occurrence. When spam (unsolicited bulk e-mail) is sent with a forged From: address pointing to one of your users (or at least an address putatively in your domain), if that spam is then rejected (bounced) by some intended spam recipient, the resulting notification messages (the bounces of the original spam messages) come back to your user, or at least your host! When one or more of your users' From: address gets forged on spam messages, this can then lead to a large volume, a "storm", of notification messages incoming to your users/hosts. One technique that can be helpful in such cases is to "isolate" incoming notification messages, as discussed in Notification message routing, and then perhaps do such things as "slow down" delivery of such notifications relative to other messages (for instance, reducing the
maxjobs for the special delivery channel) and/or perform specially rigorous scanning of such incoming notifications and, when appropriate, discard them rather than deliver them.
Another issue that can occur with notifications and spam messages is when spam messages come in to your host with forged invalid (but not immediately obvious as such) From: addresses. If the spam messages are bounced, this can lead to a large burden of notification messages (regarding the spam) which your MTA is attempting to send (deliver) to what are in fact undeliverable recipient addresses (those invalid forged purported original sender addresses). When forged From: addresses on the original spam point to domains that will result in merely temporary errors upon delivery attempts (of the notifications concerning the bounces of the original spam), your MTA's outgoing message channels can get burdened with these large numbers of notifications that will never be deliverable (but meantime are cluttering up the outbound delivery channels). One approach to deal with this is to discard (rather than bounce) such spam; however, some sites for legal or other reasons can not use such a discard approach. In such cases, use of a
notificationchannel and then a source-channel-specific rewrite rule (or CONVERSIONS mapping table entry) to route messages coming from the special
notificationchannel in turn out a special outbound channel, can prevent such messages from unduly burdening your MTA and unduly interfering with other message processing. See Notification message routing for an example of such configuration.