Repeated Blacklisting / IP reputation

Sun Sep 13 00:53:32 UTC 2009

> >>>>> "Joe" == Joe Greco <jgreco at ns.sol.net> writes:
> 
> Joe> So, you agree, MTA's do not implement this functionality.  It's
> Joe> obviously possible to make it happen through shell scripting,
> Joe> database tricks,
> 
> No, I do not agree.
> 
> The sql backend is part of the MTA; features added by offering a sql
> backend for tables of this sort (I'd use a cidr access restriction
> in postfix) are still features of the MTA.
> 
> And actually using the power of sql when using sql is not a trick;
> rather it is the /point/.
> 
> IOW, the MTA is the sum of its parts; when using sql lookups the db
> is part of the MTA.

By that argument, anything else that you install that augments the
functionality of your MTA in some manner is "part" of your MTA.  Since
DSPAM hooks into Postfix, clearly Postfix offers Bayesian filtering,
and since ClamAV hooks in, clearly Postfix offers spam filtering, and
since you can use LogReport to manage its logs, clearly Postfix offers
reporting via an HTTP interface, and since I find it convenient to have
a shell on a mail server, when I install tcsh or zsh, that's also an
offering by Postfix.

No.

You show me a line in Postfix's ACL code that reads to the effect of

if (expiryfield < time(NULL)) {
	accept_message;
}

and then that's PART of the MTA.  Otherwise, it's an add-on of some sort.
Given that the point I was making was about capabilities *included* in
the MTA, and given that I *said* you could add on such functions, it's
kind of silly to try to confuse the issue in this manner.

In other words, if it doesn't compile out of the box with it, that's what
I was talking about, and that's the point.  No add-ons, no enhancements.

We already know that something can be *added* to help the MTA implement
such a feature; that's obvious to everyone.  However, it isn't commonly
done, and dlr posted stats indicating that a significant percentage of
spam-spewing IP addresses would continue to do so for *years*.  As a
result, mail admins typically throw IP's in ACL's for something that
approaches *forever*.

The point was that MTA's don't support anything else by default, that
such a feature isn't in demand, and that the spam database analysis
supports this as a not entirely unreasonable state of affairs.

Further, since it is relatively unlikely, statistically speaking, that
any particular IP address

I'm not interested in playing semantic games about "what constitutes 
an MTA."  I *am* interested in the general problem of outdated rules 
of any sort that block access to reallocated IP space; this is a real
operational problem, both to recipients of such space, and to sites who
have blocked such space.

My tentative conclusion is that there is no realistic solution to the
overall problem.  Even within a single autonomous system, there usually
isn't a comprehensive single unified method for denying access to
services; you might have separate lists for IP in general (bogons),
access to mail systems (DNSBL's and local rules derived from bad
experiences), rules for access to various devices and services, rules
added to block syn floods from/to, etc., etc., etc.  And all of the
systems to implement these rules are more or less disjoint.

The concept of "virgin" IPv4 space is going to be a memory soon.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.