On Friday 18 March 2005 08:17, Alexander Bochmann wrote:there are many setups where the ISP or someone else runs a backup MX for his customer's domains as a service. With this configuration, the secondary MX will usually not know about valid users in the destination domain.
That, in fact, is the setup that I am operating and, yes, most of what comes through my secondary MX, at my ISP, is SPAM. Some time ago I implemented a rule that adds a (small) spam score for mail received via my secondary MX.
I'm on the flip side of that: we provide secondary MX services for some of our customers, and I've started adding a small bonus score for mail being sent *to* them through our server. I've also added meta-rules to treat certain rules more harshly.
The really annoying thing, from our standpoint, is the backscatter we have to process:
1. Spammer sends to secondary MX (us). 2. We filter out some of the more obvious spam (for the most part using our regular criteria). 3. We relay what's left to the primary MX. 4. Primary MX rejects mail to nonexistant users and mail that trips their own spam filters. 5. We generate DSNs that go to third parties or nonexistant hosts, contributing to backscatter and cluttering up our outbound queue.
The backscatter becomes a real problem in the legitimate relay situation, because it's basically unavoidable. If the spam is sent directly to you, you can accept it, discard it, or reject it, and it stops. But if you're relaying to someone, and *they* reject it, now you have to decide whether to generate a DSN or not. We've actually set up a separate queue for bounces that aren't delivered immediately, so that it won't bog down normal mail.
-- Kelson Vibber SpeedGate Communications <www.speed.net>
