[COLUG] another anti-spam link

[Angelo McComis]

Duane and Rob wrote:
> > If I'm understanding this correctly (and I may not be), it seems to be
an
> > approximate superset of to using the RBLs of dynamically-allocated
> > addresses; this looks like the generic rules would catch even
> > statically-allocated addresses assigned my ISPs.  But there are people
> 
> Most ISPs offering statically assigned IPs usually offer to set custom
> PTR records as well.
> 
> > out there (I know at least two) who run legitimate mail servers from
> > their homes yet have no control over their reverse-DNS lookup.  (One of
> > those I know doing this is technically violating his ISP's TOS, the
other
> > paid for a static address.)
> 
> This doesn't have anything to do with TOS's although it has the side
> effect of potentially enforcing it. I'm really surprised they aren't
> already having issues with RBLs due to this, because a couple of them
> either take submissions, or actively add any/all ISP customer IP ranges
> to back lists.
 
Regardless of if someone pays for a static from their ISP or not, if you are
on a Dial-up or Residential network, your IP will be published in the
RBL-DUL's. Static only means that they give you a permanent DHCP reservation
on their system. If mail is getting through OK now, I can almost bet with
100% certainty that their delivery rate is not 100%. I know for a fact that
I will turn away anyone on a residential network. 

I have a friend who has a small business, they have a 5-IP range of static
DSL IP addresses with AT&T/SBC/whoever they are this week. Although they are
"static" their reverse DNS shows as a bunch of numbers and ends with
wotnoh.sbcglobal.net.  Per their TOS, I can host on it. But I wouldn't
because upstream is only 512K, and for mail, I can't control the RDNS. It's
used for in-office internet (desktop-purpose) only.

And, IMHO, there's no such thing as running a legitimate mail server from
home _IF_ it's on a line where you don't control (or at least have the
ability to request) the Reverse DNS for the IPs you're using.  Run an
dedicated line (T1, OC3, etc.) to your house and control the DNS yourself?
Then yeah... that would be legitimate.  Hooking it up on your home network
with port 25 forwarded to your Linux box. Nope. Just because you run
Postfix, that doesn't make it "legitimate."


> > But if their DNS doesn't change before they come back, they continue
> > getting rejected on every retry.  It would make sense if this were
linked
> 
> Even soft errors will eventually be hard rejected by the sending MTA.
> 
> > with greylisting (whitelisting anyone who retries), but it doesn't
appear
> > to be.
> 
> Let me get this right, you advocate the use of RBLs, but not something
> that works in a similar fashion? :)
> 
> This guys example also has a whitelist option, which has the effect of
> also skipping postgrey, so no double whammy.
> 
> Oh and I forgot to mention the guy links to this page:
> 
> http://k2net.hakuba.jp/targrey/index.en.html
> 
> Which if I understand correctly adds a tar pit option to postgrey, and
> if they hold the connection open for x seconds/minutes (defaults to 65)
> it accepts the mail rather then delaying it, but also delays it if they
> drop out before the tar pit timeout.
> 
> Actually he has a pretty graph on his site, at 65 seconds tar pitting
> with postgrey he claims (july '07) 93% of spam was stopped, but at 121
> seconds it stopped what looks like 100%.
> 
> Anyways, tar pitting + postgrey looks like what I was after previously,
> which should have the effect of reducing greylisting times if they wait
> out the 65 seconds, and it will also have the effect of slow the
> spamming scum down, although I'm not sure at what cost in terms of
> resources and potential DoS to my server, although the S25R stuff should
> get most of it.
> 

I wouldn't recommend tarpitting on a high volume inbound MTA. Why let them
take up _your_ resources by holding open the connection when greylisting
(sending them home with a 451-come-back-later message) works just as well.
Obviously, there are some instances of servers who retry, but the second try
comes from another IP, and it can take forever (or fail) to get that
message.  But I've only seen that one or two times in my travels.

Angelo