ietf-asrg
[Top] [All Lists]

[Asrg] new to the list...

2003-03-05 12:04:11
Hi,

I'm new to this list; but I've been quietly fighting spam for some time on
my domains.  As a form of introduction, here is what I'm doing to fight
spam, and a simple idea for reducing the spoofed IP attempts.

I realize much may already have been discussed here; but, trying to read
the archives was just too painful, so I decided to jump right in...  :>

Yesterday, got 3 failed attempts and no spam... so my anti-spam measures
seem to be working so far.

My general feelings are that spammers will not follow any rules, except
those they can't circumvent.  So, it's up to me to force the spam attempts
through a mine-field before a message can even start to be delivered... 
any legit mailers that get caught are usually resolved by convincing the
user/ISP to correct their configs...  yes, it *does* work -- sometimes, a
penalty for not correcting when sufficiently warned is required... :^)

My main defenses are:

0. I turn *some* delivery failures into a bounce to the registered owner
of the domain (in one case, the bounces went to the providing telco -- boy
did that one stop fast... :^).  Bouncing is only done as a last resort --
today, I do this with @21cn.com and @cyberproxy.com.  Interestingly, the
latter sent me a couple of msgs claiming that the source was really in
Madrid, Spain with a bogus "that's where we've tracked it to" -- yet,
since implementing my counter-measure, the IP spoofed
checker(_at_)cyberproxy(_dot_)com attempts have virtually stopped...  :>

1. sender must be in DNS -- including reverse lookup
   Large companies like Ameritrade and BellSouth have corrected this,
though slowly, when I used step #0 on them...  :>

2. EHLO/HELO must match

3. valid userids must be used; no long number, etc.

4. using *my* IP/hostname in EHLO/HELO gets bounced with a nasty 550
response.

5. changed default 450 responses to 550 -- this greatly reduced the
retries.

6. rare spam that makes it through now is usually from some DSL user in
.br

7. probably an average of once a week now, my mailer queries an RBL.

8. fixed (non-spoofed) IP addresses which won't give up are a very short
list here:
   211.154.65.253 is the only one permanently blocked in my iptables

9. use of pop-before-smtp

Probably other means that escape me at the moment; but I don't use any
spam filters which work on mail already delivered...  I no longer see
false-positives for me and my users, except those who fail the above
tests...  usually, the senders or their ISPs fix their DNS/mailhost_name
problems...

I have my postfix setup to email me with information on every delivery
failure -- this is currently quite manageable, though a bit of hell for a
while...  even the cron daily failure reports (scanning of logs) are now
very short.

Now that I've said this,  some scumbag will try to swamp me...  :>

Looking forward to some *simple* solutions to the spam problem...

Something I've been thinking about relates to IP spoofers...  in those
cases, the spammer simply continues to blindly send -- it just gets
rejected anyway...  I'm wondering about some "challenge" that any and all
spammer implementations would not be able to get around...  one idea I'm
wondering about is this:  what if my mailer did a temporary (one packet)
partial close of the TCP window (down to some small non-zero value)
forcing the sender to respect it.  Failure to do so, would indicate either
a blind spoofer or broken stack... either way, resulting in an immediate
FIN.

Anyway, just wanted to throw in my experiences to date which are quite
simple, yet quite successful...

HTH,
Pierre (retired)
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>