Very interesting discussion. I run a secondary MX without SA, which normally forwards everything to the primary, IOW a store-and-forward relay. The secondary gets a steady stream of spam all day long, about 1/3 as much as the primary. I tried the trick with a tertiary entry matching the primary, but it didn't reduce the spam at the secondary very much.
SA on the primary penalizes mail coming via the secondary with 2.0 points. Obviously SA won't be running if the primary is down, and if we ever get a long primary outage I can disable this rule on restart. To eliminate backscatter, I copy the LDAP-generated sendmail "access" database from the primary to the secondary twice a day. Thus the secondary will not accept mail for nonexistent addresses. The time lag isn't a problem, since the secondary only gets legitimate mail when the primary is down, which is almost never. Pierre -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, March 18, 2005 1:40 PM To: [EMAIL PROTECTED]; users@spamassassin.apache.org Subject: RE: Spammers Target Secondary MX hosts? Kelson wrote: > Larry Starr wrote: >> 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. Two solutions occur to me: 1) Allow a way for the secondary MX to tell whether the primary MX is "up" - if it is, don't accept any connections 2) Allow a way for the secondary MX to tell what email addresses on the primary MX are valid (LDAP occurs to me) Matthew.van.Eerde (at) hbinc.com 805.964.4554 x902 Hispanic Business Inc./HireDiversity.com Software Engineer perl -e"map{y/a-z/l-za-k/;print}shift" "Jjhi pcdiwtg Ptga wprztg,"
