"Joe" == Joe Greco <jgreco@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.