No. This has been discussed before. It's a major rewrite for no discernible benefit.
Jeff
You may disagree with me all you want, the fact remains that there's no discernable benefit to switching to postfix.HI Jeff, while I know you are the (anti) spam master, postfix does have MANY features that exim does not. Sorry but I have to disagree with you.
Okay, which ones do you want? And why? Either I'll implement them (and that's the advantage of constructive criticism) or I'll have a reason why I don't want to implement them and then you can of course; all it takes is a rudimentary knowledge of the exim.conf file and a good exim reference (they're available both in book form and online); after all, that's how I did it. That's the advantage of open source.Some of the basic SMTP level checks postfix has that exim does not to name one major advantage. Helps block spammers at the SMTP level.
That's simply spreading FUD unless you can quote specific things that are important to the anti-spam community that you know exim cannot do.We've put postfix in front of all of our shared hosting server (with many other anti-spam mods) that postfix can do and blows aways exim could ever do. postfix is so much more flexible.
It's certainly not true thqt you have to use the default exim setup (either the one published at exim.org, or the default exim setup that comes with DirectAdmin; we know that it's no longer that good, and my understanding is that DirectAdmin is only waiting for my finishing touches on the new version of the exim.conf file before updating it (I could be wrong; you're welcome to ask them). But you can create your own. At least one of the spam-filter organizations uses exim.conf (with a custom exim.conf file) as their main system for managing spam.The default exim setup (we have to use on our reseller servers) gets so much more spam it's not even funny.
That's simply spreading FUD unless you can quote specific things that are important to the anti-spam community that you know exim cannot do.
We have so many clients in Europe with no problems accessing our Web site. However, one man from Sweden contacted us recently with the same problem as yours. When he looked into it further, he discovered it was a problem with his ISP's Nameservers. To troubleshoot this problem, I suggest you do the following:Andy, perhaps is better to first tune your server so that visitors from Europe can read it too. It has been said to you before but servertune.com still shows a blank page.
Let's see...FUD no.
While exim is quite capable of blocking on IP classes and subnets, no, it doesn't by itself do complex regex blocking. Exim's head designer believes that you should use external programs to do what Exim doesn't do, and he gives us lots of hooks to do that. The DirectAdmin exim.conf file already does some of those, and you can add others. I don't see any reason to move away from Exim to add these features.Features that postfix has that Exim doesn't:
- REGEX blocking of headers source IP, From, Tos, and body, built into postfix (this has help us block many dynamic IPs (by REGEX name) that are spambot havens) Many spambots can't even knock on our door.
Simply not true; exim certainly can warn; it's an easy change in the exim.conf file and will either log or place new headers or both.- ability to test rules "warn_if_reject" before they put into production
Exim fully supports MySQL for any of it's lookups. It's just something I don't do.- whitelisting/blacklisting supports mysql tables (which is powerful for our centralized anti-spam to block all incoming mail servers with just one change and in realtime. No RBLdns cache delay)
Of course you can reorder any acl in exim. We do so all the time in our testing, and there will be more changes before the final release of the next version.- custom ordering of rule checks, whitelisting, blacklist (RBLs and local files) and SMTP and header checks
exim.conf is certainly flexible enough to do that; I don't do it in SpamBlocker only because there's no interface for it in DirectAdmin.- can get a complex as custom filtering per from, to or IP address (meaning disable some filtering per a specific customer's needs)
Have you ever looked at the exim specification and the exim.conf file. There are a lot more hooks for acls than I use in SpamBlocker.- Can customize checks every level through the SMTP communication: HELO, MAIL FROM: RCPT TO: and DATA. Add/delete checks as you see fit..
I'm not sure what you mean by addon; the ACLs built into exim via exim.conf are certainly not an addon.- Validate SMTP HELOs (built into postfix not a addon)
I haven't researched this; if it's true, then it's only one out of your list, but I really don't know.- throttle incoming smtp connects from the same IP.
I would hope that you'd be willing to share some of your custom filtering with the community at large, so we may determine how to best implement in what we've got. Please consider that.I can see this is a loosing battle, which is fine with us. We have the luxury of a centralized anti-spam setup using postfix as the basis and exim is just for customer outgoing SMTP and final destination of emails from the anti-spam servers. Postfix and our custom anti-spam filtering, and open source layers in front of all of our DA servers.
On our reference server running the SpamBlocker 3.1-beta, the blocklists and other features built into the SpamBlocker exim.conf file manage to block well over 90% of the email reaching the server. Sure we use SpamAssassin to do the heuristic checking and the pattern match checking after that; simply because it's already built into the DirectAdmin interface. Personally I believe exim supports more flexibility than any other MTA in general use today, and the article posted at Andy Reed's website seems to reach the same conclusion.Many other customers do not have this luxury. With spam over 90% of all email it's critical that the DA spam solution isn't just using SpamAssassin to do the brunt work. My basic point is most blocking should occur at the SMTP level, not after. Exim does not appear to support much needed flexibility. From looking at all of the latest SpamBlocker (3.1) it appears still too much is at the SpamAssassin level.
I tried the published solutions for using greylisting with exim, and found they didn't work as advertised; exim simply didn't work once I'd added them. I suppose that's my limitation. So I studied nolisting, which has worked well for me as an alternative.What other spam filtering options? Specifically in SpamBlocker and exim:
- Greylisting (still about 20-30% effective and if done properly little downside)
I'm still awaiting constructive criticism. What do you want me to check for?- more SMTP validation and header checking
They're easy enough for you or I to add. Why should I add them?- more rhsbl (surbl.org and uribl.com)
I presume this addressed to JBMC, the company which produces DirectAdmin. So I won't go into it except to say that I encourage anyone else to get involved in making SpamBlocker better; it's open source. And to point out that I'd be personally against the idea of DirectAdmin partnering with an anti-spam service provider; I think that should be left up to individual DirectAdmin licensees, their providers, and their data centers. I know I wouldn't want to see a license fee added to DirectAdmin, and to have a feed through a specific anti-spam service provider, as part of DirectAdmin.I see others like hostpc.com also doing the same as we are doing (using a centralized anti-spam system), so we're not alone. My recommendation is either make what you have better and/or partner with an anti-spam service provider to take the load off our the DA servers.
That's the beauty OF postfix, it's already built in. In today's spam world REGEX IS a big part of the arsenal for spam filtering. It's used quite a bit and IMHO should be part of the MTA. For example SpamAssassin is primarily one BIG REGEX.While exim is quite capable of blocking on IP classes and subnets, no, it doesn't by itself do complex regex blocking.
exim.conf is certainly flexible enough to do that; I don't do it in SpamBlocker only because there's no interface for it in DirectAdmin.
I'm not sure what you mean by addon; the ACLs built into exim via exim.conf are certainly not an addon.
# IF YOU CHECK FOR VALID HELO:
# UNCOMMENT THIS SECTION
# WARNING THIS IS UNTESTED AND MAY BREAK ABILITY FOR USERS TO SEND EMAIL THROUGH YOUR SERVER
# deny message = Single word server helo name ($sender_helo_name) rather than a FQDN.
# condition = ${if ! match {$sender_helo_name}{\N^[^.].*\.[^.]+$\N}}
# deny message = IP# server helo name ($sender_helo_name) rather than a FQDN.
# condition = ${if match {$sender_helo_name} {^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\$|^\[[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\]\$} {yes}{no}}
I would hope that you'd be willing to share some of your custom filtering with the community at large, so we may determine how to best implement in what we've got. Please consider that.
So I studied nolisting, which has worked well for me as an alternative.
They're easy enough for you or I to add. Why should I add them?
And to point out that I'd be personally against the idea of DirectAdmin partnering with an anti-spam service provider; I think that should be left up to individual DirectAdmin licensees, their providers, and their data centers. I know I wouldn't want to see a license fee added to DirectAdmin, and to have a feed through a specific anti-spam service provider, as part of DirectAdmin.
It's been my experience that most of us understand regexes just enough to get us in trouble. Big trouble. That said if someone wants to write it, I'll include it in my exim configuration. (Note I say my and not our because I don't speak for DirectAdmin's authors.)That's the beauty OF postfix, it's already built in. In today's spam world REGEX IS a big part of the arsenal for spam filtering.
That's a great example. Which not many of us would ever figure out how to implement.For a simple example, want to block all Verizon dynamic IPs (which is a huge source of spam)
/^pool-.+-.+-.+-.+\..+\..+\.verizon\.net$/ REJECT Must use providers mail server for outgoing Email - access
I can't speak for others, but in general I'd rather let the experts figure out who's sending the spam, and use their blocklists. I never said that SpamBlocker was all anyone would ever need. Certainly it doesn't work for you and I respect that. But I don't think all of us are as willing to become experts in spam control as you are; I think many of us, like me, want solutions that just work in terms of eliminating most of the spam.Yes I know there are RBLs offer dynamic IP lists but are not perfect and if you aren't rsyncing the RBL local adds additional overhead.
More correctly it requires that someone research and writes the code, and that the rest of us simply use it. I don't know why you call that a fork, but I won't argue the point.In exim you must create a perl script, debug and test in order to do this. This then also means an additional fork (which means more overhead)
For those who don't have the luxury of taking the time to go back and reread previous posts to know what's being quoted: empowering is writing further about per-user/per-domain selections of blocklists. Exim's documentation is not in the form of a cookbook, though many people have written their own, and some of them can be found on the 'net.Haven't seen any documentation within exim to do this, and did not know this existed.
And it's built into the exim.conf file you've already got; you quoted it above. I picked up the code from another exim user some time ago (perhaps years, even), and I include it with a word of the dangers.Specifically in the SpamBlocker code...
Code:# IF YOU CHECK FOR VALID HELO: # UNCOMMENT THIS SECTION # WARNING THIS IS UNTESTED AND MAY BREAK ABILITY FOR USERS TO SEND EMAIL THROUGH YOUR SERVER # deny message = Single word server helo name ($sender_helo_name) rather than a FQDN. # condition = ${if ! match {$sender_helo_name}{\N^[^.].*\.[^.]+$\N}} # deny message = IP# server helo name ($sender_helo_name) rather than a FQDN. # condition = ${if match {$sender_helo_name} {^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\$|^\[[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+\]\$} {yes}{no}}
This functionality is built into Postfix
Actually it looks as if you and I use a lot of the same ideas, though we implement them quite differently. Some of that is because we're different people, some of that is because DirectAdmin is a hosting panel, and not a spam-control panel (our commercial product may or may not exist some day), and most of it is because we're very different people.While I won't give details our customizations/additions/mods we've spent months developing and maintaining, I will mention all of the open source parts These cover most of filtering:
- Postfix (duh)
- SQLgrey
- amavis-new
- SpamAssassin
- policyd-weight (no longer maintained) - Uses scoring with RBLs, SMTP HELO, and other SMTP tests to determine if the email should pass through.
- clamav
As I wrote previously, we block about 90% of all incoming email outright on the server I use for testing (one of the domains on it used to be a now-defunct ISP; it attracts a lot of spam). It appears that for us we do as well as you do for you.We have this setup on two dedicated servers that see about 350-400k emails daily, 80-85% is rejected outright and 5-10% marked and delivered as spam (by spamassassin)
I'd guess that most DirectAdmin users have single servers. Perhaps I'm wrong.For a single server, yes nolisting is a decent alternative.
I don't think that's a task most small webhosting companies using DirectAdmin want to take on; perhaps I'm wrong. I think I'm going to build a standalone system for greylisting, but that defunct ISP on it, and see how valuable the information becomes. Of course that still doesn't mean my data would be valuable to others, or that others would want the complexity of keeping up with it, but perhaps we could end up with our own blocklist for our clients.We don't use it with our centralized setup. We have two active MX records. I say bring on the spammers to the backup MX record. It helps us figure out who are not legit senders (as part of a honeypot and early detection system)
Again, for clarity, empowering is referring to adding surbl.org and uribl.com. I've visited that blog and see no links on the front page to rhsbl, to surbl.org, and to uribl.com. Can you be more specific as to what to read?So they are included in the default setup. Both are VERY effective RBLs and I believe most DA customers can benefit from them. If not reading already I suggest reading this blog:
http://www.dnsbl.com/
empowering is referring to DirectAdmin partnering with a third party anti-spam provider. That would be up to them to respond to; I don't speak for them.I'm not saying make it a requirement, as an additional add-on for larger customers or customers who want something more effective. I don't know what percentage of DA customers have more than one DA license but I suspect many.
I'm looking at it this way. All customers (the end users of the product) are seeing more spam in their inbox with the existing SpamBlocker. They aren't happy about it and in some cases complain to their provider (I've even seen switch providers). The DA providers are then looking for alternatives.
Well then certainly you see the importance of testing, which is why it's still beta.I will install SpamBlocker on our reseller and customers who aren't paying for our anti-spam service and see what difference it makes... After it's not beta
But what I will say for certain is that if you're not willing to use the latest code after being told the old code is not as good by a factor of several magnitudes, then that's your decision.
Early adopters, who are using it, and who are providing me with valuable feedback, are already saying things like this unsolicited comments after we installed the upgrade to SpamBlocker 3.1-beta for one client):
Having some very positive comments from clients re spam reduction
Jeff
More correctly it requires that someone research and writes the code, and that the rest of us simply use it. I don't know why you call that a fork, but I won't argue the point.
Again, for clarity, empowering is referring to adding surbl.org and uribl.com. I've visited that blog and see no links on the front page to rhsbl, to surbl.org, and to uribl.com. Can you be more specific as to what to read?