How to stop Backscatter Spam

I need help to get rid off the Backscatter Spam.

I am running version 5.X and have implemented some sugguestion from other on how to get rid of Blackscatter.
However, I am still getting thousand thousand of these Returned, Undelivered mail.
Do you have a working configuration to share. I am hoping Zambra has this capability.
There are only 10 users on this pilot server. Is there a way to get this function turn on and work correctly
once for all.

Backscatter and Spam Confirmation

Mark,

Is it true, Zimbra capable of allow only Users and Domains that created/allowed by our Zimbra server for outgoing email?

It is also true to prevent/stop this type of backscatter attack the domains that get Spam SHOULD HAS THEIR MAIL SERVER REVERSE LOOKUP TURN ON to verify the impostor has the right IP address with the MX before their email server accepting incoming email, right?

off course, for us we need to implement the informtion that you had sugguested to prevent these bounce/retured/undelivered email, correct?

Is it true, Zimbra capable of allow only Users and Domains that created/allowed by our Zimbra server for outgoing email?

It is also true to prevent/stop this type of backscatter attack the domains that get Spam SHOULD HAS THEIR MAIL SERVER REVERSE LOOKUP TURN ON to verify the impostor has the right IP address with the MX before their email server accepting incoming email, right?

off course, for us we need to implement the informtion that you had sugguested to prevent these bounce/retured/undelivered email, correct?

Thank you,

Y

The only Postfix DNS check we do in Zimbra is reject_unknown_sender_domain, which you can enable from the Administration console.

I think you may also want to look at the SpamAssassin V_Bounce filter, and search the forums here for tips on enhancing the score that check gives to emails.

I think also you need to know if your users are OK with not receiving any NDRs (Non-Delivery Receipts) at all, because if so, then you can add some Postfix regular expressions as the Postfix readme link I posted indicates to block such emails.

There are also posts on this forum about adding Postfix regular expressions to Zimbra to help with mail filtering.

Since 99.99% of all my backscatter email is coming from domains I have never sent mail to, I was thinking that a simple solution might be possible. though not perfect solution.

1) Make an automatic white list for every domain mail is sent to.
2) When a bounced message is received, the domain in the header is checked against the white list. If there is a match, the subject is rewritten to something like "Zimbra Is Notifying you of a bounced email". For every thing not on the whitelist, rewrite the header as "Unconfirmed bounced message"
3) Add a filter to move email messages containing the subject 'Unconfirmed bounced email" to a mailbox named 'Bounced' or to the Junk folder. Tell the filter to not move any message with the subject "Zimbra Is Notifying you of a bounced email"

What we are seeing is that almost all legitimate bounce messages are due either to the recipient's mailbox being over-quota, or to the sender mistyping the recipient (e.g. a0l.com instead of aol.com being one of the more common we see).

In the first case, the recipient will quickly figure out they are over-quota, because they will not be receiving any new emails. Once the quota issue is resolved inbound email (hopefully deferred) will start flowing again. No need to bother the sender with an NDR; they couldn't fix the recipient's problem anyway, although the recipient might learn about the problem a little sooner.

In the second case, our experience has been that users will readily choose "no NDRs at all, including legitimate NDRs" just to avoid the torrent of illegitimate bounces. If, as a result, the user is just a bit more careful about typing in an email address, so much the better. Certainly, the look-ahead feature in the Zimbra compose window helps to eliminate a lot of potential email address typing mistakes.

Given the foregoing, we have therefore become pretty aggressive at blocking NDRs in principle (we use a few Postfix regular expressions), and educating our users accordingly.

So far, no complaints!

Also, if your script plan just whitelists domains, you'll still get a lot of bogus NDRs. If your script whitelists only recipient email addresses, then how do propose to handle aliases? I think you could easily wind up with a very complex script that will need to be maintained pretty regularly to be effective; I'm wondering if our "less is more" approach might serve you and your users better?