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&#x27; 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    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&#x27;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   and then a  source-channel-specific rewrite rule (or  CONVERSIONS mapping table  entry) to route messages coming from the special    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.

See also:
 * Notification messages
 * Notification message routing
 * maxjobs Option
 * notificationchannel Option
 * CONVERSIONS mapping table