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," 

Reply via email to