Summary: The default virtualmin postfix config causes backscatter spam and a solution is needed. None of the solutions I tried worked.
My IP address was recently blacklisted at backscatterer.org. Usually this is because mail to non-existent users (such as typo@mydomain) is bouncing back to fictitious senders instead of being rejected or discarded, but Virtualmin configures that pretty well. In my case, incoming spam was being forwarded to a third party which rejected it immediately and my postfix server tried to inform the fictitious senders with a bounce message that seemed to come from me. This is bad and Iām surprised postfix (and virtualmin) is configured like this by default.
The possible solutions I can see are:
Use spamassassin to reject incoming spam before it is forwarded. I donāt like this because I donāt store mail, I only forward it and spamassassin can cause false positives and false negatives. (I did nevertheless try enabling spamassassin but with disastrous results, see separate thread.)
Check that the third party server will accept forwarded mail before completing the incoming transfer. Postfix can be configured to do this as described in www.postfix.org/ADDRESS_VERIFICATION_README.html but it slows things down and has limitations.
Filter out third-party bounces and discard them as described in http://taint.org/2007/05/30/164456a.html. This looks promising but I couldnāt get it to work, even with a bounce message that contained the correct trigger. Perhaps somethingās wrong with the regex or with header filtering?
Use spamassassin to filter out the third-party bounces. This has other benefits as described at http://taint.org/2007/05/30/164456a.html so I tried enabling spamassassin including the āVirus-bounce rulesetā. I couldnāt get that to work either.
Configure postfix to prevent it sending to any address thatās not on a white list of āforward toā addresses. That would prevent mailing lists working and would require a lot of maintenance so I havenāt tried it.
Has anyone found a solution that works? Iāve googled extensively and spent hours on this without success.
Iām wondering hereā¦ Isnāt this expected behavior? If you configure your Postfix as a forwarding-only system without any spam checks, it will first fully receive the message, close the incoming connection, and then try to forward it. Thatās simply because receiving, sorting and processing (delivery attempt) are separate processes and cannot be done in one step.
When the system youāre trying to forward to then rejects the mail, your Postfix has no chance but to send an NDR to the apparent original sender, since its SMTP session has already been closed.
Yes, thatās exactly how it was designed. Then the spammers discovered they could forge the sender address and get their spam out that way, which means itās now worse than useless. So we either have to reject the message while the incoming connection is still open, or not at all.
I tried options 2 (address verification) and 3 (discard 3rd party bounces) in my original post but I can now report that they donāt stop the backscatter. Nor does option 4 (spamassassin). In all cases I think the problem is that the backscattered message is triggered not by an email message that can be parsed, but by a delivery rejection.
The ābounce-neverā command filter option described at www.postfix.org/postconf.5.html.
/etc/postfix/main.cf:
smtpd_command_filter = pcre:/etc/postfix/command_filter
/etc/postfix/command_filter:
# Bounce-never mail sink. Use notify_classes=bounce,resource,software
# to send bounced mail to the postmaster (with message body removed).
/^(RCPT\s+TO:.?)\bNOTIFY=\S+\b(.)/ $1 NOTIFY=NEVER $2
/^(RCPT\s+TO:.*)/ $1 NOTIFY=NEVER
This sort of works, but floods the postmaster with bounces.
The āsoft-bounceā option also described at www.postfix.org/postconf.5.html. This also sort of works, but fills the mail queue with bounces.
The downside is that mail that is forwarded to a third party such as gmail but not delivered for whatever reason may silently vanish, unlike mail sent directly to gmail without going through my server which would show a rejection reason. I know of no possible solution to that which doesnāt involve backscatter and hence blacklisting as previously, or the possibility of valid mail occasionally disappearing without warning (the spamassassin solution).
Iāve made some progress so I thought Iād update the thread.
Setting the bounce handler to ādiscardā does effectively prevent backscatter problems but is not an ideal solution because you sometimes need to see the bounce messages.
I actually contacted Wietse Venema (postfix architect) about this but his only advice was to enable spam filtering so spam doesnāt get forwarded in the first place. The problem is spam filtering is never perfect so some spam still gets through - and even worse, false positives stop some genuine mail getting through. And filtering in the forwarding server prevents the end user doing any bayesian training. At the time I couldnāt get spam filtering working on forwarded mail anyway and Wietse was quite rude about it so I gave up.
I have now discovered how to make spam filtering work on forwarded messages - you have to set up a filter in Usermin (which I wasnāt using before, since my users donāt use local mail storage). The problem is, the CPU load it caused (even running as a daemon, with local DNS resolution etc.) was bringing my VPS to its knees.
To cut a long story short, I ended up moving to a more expensive hosting provider (www.transip.eu) that had a more up to date OS (and KVM hypervisor) that allowed me to run the postfix postscreen module. This has greatly reduced the volume of spam flowing through my system, which in turn has reduced backscatter. The other big benefit is that mail is getting through more reliably to big providers like Gmail and AOL who sometimes blacklist servers that forward too much spam.
So my advice is to enable postscreen if possible if youāre forwarding mail. Itās a bit fiddly to set up (youāll probably need to register at barracuda, for example) and it can cause genuine mail to be delayed sometimes, a bit like greylisting. But on the whole it makes a big difference without causing false positives.
The spam messages reaching my personal account dropped from around 800/day to 5/day just by doing this! Be aware that a LOT of log messages will be generated in the process, and thereās no way to disable them.
By the way, I put a more general Virtualmin tutorial on my web site at www.mckerracher.net/vps if that helps.
Oh, and to get forwarded mails to be filtered by Spamassassin and ClamAV you need to first enable them in Virtualmin > System Settings > Feature and Plugins, then make any adjustments in Virtualmin > Email Messages > Spam and Virus Scanning (select whether to run as daemons or not).
Then select every individual user one by one (it took me hours) and under Mail Forwarding settings select āDeliver to this user normallyā (and remove any existing forwarding, perhaps cutting the addresses to your clipboard). Then click the āLogin to Userminā button and select āForward Emailā and select āEmail forwarding enabledā and paste the desired forwarding addresses there.
Then click Email Filters > Add a new email filter and select All email, Perform spam classification, Continue with other filter rules and click Create. Move this rule to the top of the list.
Should this Postscreen enabling/configuring functionality be added to Virtualminās āEmail Messages/ Spam and Virus Scanningā module ? Seems like all the nitty gritty could be better handled automatically and result in minutes rather than hours of downtime, with less chance of messing up the postfix config files ?
In case anyone finds this old thread, Iāve found some problems with forwarding using Usermin that make it less than useful. By default bounce messages are suppressed and they must be, otherwise you can get forwarding loops (as I discovered the hard way). But this means userās arenāt aware if forwarded mail delivery fails at the destination. Also, certain āmagicā addresses such as the useful admin@ never get forwarded at all.
The solution for me was to do the forwarding in virtualmin rather than usermin. This is simpler in many ways but it does bring us back to the original problem mentioned in this thread - Gmail rejects the forwarded messages because the spam filtering headers havenāt been added yet.
The solution for me was to install Amavisd-new to control the spam and virus filtering before messages get forwarded. This works really well (less spam getting through) but thereās no webmin module for it so you have to set it up from the command line.
So, to come back to the topic of backscatter spam and postscreen - yes, I definitely think postscreen support should be added to Webmin, along with Amavis support. And while weāre at it, postsrsd support as well because otherwise SPF will break for forwarded mail.
In file /etc/amavis/conf.d/50-user I add the following lines so that only the most severe spam is discarded and the rest is passed through (not quarantined) so users can see it in their Spam folder and drag it to their Inbox to train their spam filter if necessary.
