Postfix support

kaioz

New member
Joined
Feb 27, 2008
Messages
3
Is there any plan to support Postfix instead of Exim or as an alternative?

Thanks in advice!
 
No. This has been discussed before. It's a major rewrite for no discernible benefit.

Jeff
 
No. This has been discussed before. It's a major rewrite for no discernible benefit.

Jeff

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.

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.

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.

The default exim setup (we have to use on our reseller servers) gets so much more spam it's not even funny.
 
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.
You may disagree with me all you want, the fact remains that there's no discernable benefit to switching to postfix.

There are indeed many benefits that you know how to control in postfix that aren't in our exim implementation simply because I'm not the anti-spam master you seem to think I am. As I've written previously on these forums, I wrote the SpamBlocker exim.conf file for my own use back when DirectAdmin was still using the Exim version3 exim.conf file, run through a conversion program to make it work (poorly) with Exim version4.

I wrote it for my own use; I posted it on these forums, and DirectAdmin staff thought it enough of an improvement to use. And I've kept it updated as best I can over the years.
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.
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.

Or of course you may convince the DirectAdmin staff of anything you want. I doubt they'll switch to postfix, though; it requires a major rewrite to much of how DirectAdmin handles virtual domains. Or maybe not; perhaps you can teach them. It's unlikely you can teach me because exim does all I've ever needed or wanted.
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.
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.
The default exim setup (we have to use on our reseller servers) gets so much more spam it's not even funny.
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.

Again, please feel free to reply with exactly what SMTP level checks you'd like to see in exim.conf.

Jeff
 
Hello,

We'd have to see some serious benefits to switching to postfix to even consider it. As Jeff mentioned, exim is very engrained into our setup so swapping it out would be rather difficult. Exim is very flexible and configurable, so if there are any features you think should be added to the setup, post your thoughts and they can be discussed and evaluated.

A quick smtp-time google for exim did return this:
http://marc.merlins.org/linux/exim/sa.html
(of numerous results).. I have not looked at it in much detail.. it likely requires a Makefile change and recompile.. looks to be about 2 years old.
This looks like the sa-exim sourceforge page:
http://sourceforge.net/projects/sa-exim/

John
 
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.
 
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.

FUD no.

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.
- ability to test rules "warn_if_reject" before they put into production
- 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)
- custom ordering of rule checks, whitelisting, blacklist (RBLs and local files) and SMTP and header checks
- can get a complex as custom filtering per from, to or IP address (meaning disable some filtering per a specific customer's needs)
- Can customize checks every level through the SMTP communication: HELO, MAIL FROM: RCPT TO: and DATA. Add/delete checks as you see fit..
- Validate SMTP HELOs (built into postfix not a addon)
- throttle incoming smtp connects from the same IP.

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.

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.

What other spam filtering options? Specifically in SpamBlocker and exim:

- Greylisting (still about 20-30% effective and if done properly little downside)
- more SMTP validation and header checking
- more rhsbl (surbl.org and uribl.com)

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.
 
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.
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:
1. From your own PC and/or from http://www.all-nettools.com/toolbox, ping our Web site: servertune.com and/or our IP address: 207.250.188.6

Try accessing our alias domain: www.ServerTune.net

Please, send me a private message at: andyreed [at] servertune.com and let me know what you got. Thank you
 
Let's see...
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.
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.
- ability to test rules "warn_if_reject" before they put into production
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.
- 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)
Exim fully supports MySQL for any of it's lookups. It's just something I don't do.
- custom ordering of rule checks, whitelisting, blacklist (RBLs and local files) and SMTP and header checks
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.
- can get a complex as custom filtering per from, to or IP address (meaning disable some filtering per a specific customer's needs)
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 customize checks every level through the SMTP communication: HELO, MAIL FROM: RCPT TO: and DATA. Add/delete checks as you see fit..
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.
- Validate SMTP HELOs (built into postfix not a addon)
I'm not sure what you mean by addon; the ACLs built into exim via exim.conf are certainly not an addon.
- throttle incoming smtp connects from the same IP.
I haven't researched this; if it's true, then it's only one out of your list, but I really don't know.
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.
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.
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.
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.

Which of course doesn't mean that it's not the right solution for you.

However I personally believe it's the best solution for a shared server designed to serve websites.
What other spam filtering options? Specifically in SpamBlocker and exim:

- Greylisting (still about 20-30% effective and if done properly little downside)
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.

We simply create an A record in DNS to point mx0.example.com to point to an IP# (on any server) which doesn't answer on port 25, and then we set up an mx record with a value (cost) of 0, for the domain. This works well for us and has cut a lot of email from our servers.
- more SMTP validation and header checking
I'm still awaiting constructive criticism. What do you want me to check for?
- more rhsbl (surbl.org and uribl.com)
They're easy enough for you or I to add. Why should I add them?
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.
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.

Note that I'm just one lone voice in the crowd. I don't believe that JBMC (the company) listens to me; I think it more likely that I understand how exim integrates into DirectAdmin, and I understand it's strengths and its weaknesses, so we reach the same conclusions.

Jeff
 
While exim is quite capable of blocking on IP classes and subnets, no, it doesn't by itself do complex regex blocking.
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.

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

done problem solved. We don't allow many of the offending ISPs with spambots to send mail to our servers. Works VERY well and haven't had a legit complaint yet. 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.

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)

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.

Haven't seen any documentation within exim to do this, and did not know this existed.

I'm not sure what you mean by addon; the ACLs built into exim via exim.conf are certainly not an addon.

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

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.

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

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)

So I studied nolisting, which has worked well for me as an alternative.

For a single server, yes nolisting is a decent alternative. 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)

They're easy enough for you or I to add. Why should I add them?

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/

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'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.

SpamBlocker 3.1 might be a "good enough" option, other providers might be looking for something still more effective. I'm seeing spam filtering becoming a tiered option. How effective and how important is your Email inbox?

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 :-)
 
Last edited:
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 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.)
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
That's a great example. Which not many of us would ever figure out how to implement.
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.
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.

Nevertheless, if someone writes the code, or if I can find that someone in exim-users has and is willing to share it, I'm willing to include it.
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)
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.
Haven't seen any documentation within exim to do this, and did not know this existed.
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.

Suffice it to say it's not hard and in fact we've already done the specification for it for a commercial spamblocking front-end solution. I haven't worked on it for over a year because I've been too busy taking care of clients.
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
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.

Sure it's dangerous. It may be dangerous with Postfix as well; the problem is that many legitimate senders use single-word helo names; you can use the code if you want.
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
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.

One major difference between the two of us appears to be that you don't want to share your techniques with us, and I do.

Which is certainly fine with me.
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)
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.

I understand that you're using dedicated email servers; I don't think that's a major interest of most DirectAdmin users; if it becomes so there are a lot of commercial products on the market, or they can create their own (as you did), or they can wait (perhaps forever) to see if mine ever comes out.
For a single server, yes nolisting is a decent alternative.
I'd guess that most DirectAdmin users have single servers. Perhaps I'm wrong.
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)
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.
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/
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?
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.
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'd bet they're as tired of this thread as I am, so I suggest you contact them directly with this suggestion, or at least make it a new thread.
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.
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 :-)
Well then certainly you see the importance of testing, which is why it's still 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.

I donno if you are confused about what I meant. When I say fork, not a fork in the development code. A fork process in unix is creating new process

http://www.scit.wlv.ac.uk/cgi-bin/mansec?2+fork

In general, creating forked processes adds a lot of overhead. Something like spam filtering that consumes a lot of resources you try to avoid doing.
 
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?

On that web site there is no mention of those two specific RHSBL (Right Hand Side Blacklist). The general consensus on the net is both these are effective and I agree.

The URL given (http://www.dnsbl.com/) is great to see real stats on the effectiveness and FP (false positives) of the more popular RBLs used.
 
Hi there,

As a hosting company it's our responsiblity to block SPAM not our CP vendors. They use a pretty standard MTA (that's mail transfer agent, not anti-spam gateway, mail blocking service) so we include MailScanner in our default shared hosting build.

We have 65+ Servers doing it this way with extremely effective results with on average of 1200 domains per server.

This has worked well for us since 2004 when we had a few servers until 2008 where we have thousands of servers spread between many different data centres.

Let the DA boys get on with their control panel and let the people who know what they are doing, do.

Paul
 
Last edited:
Back
Top