Ok, so we all know spam is a killer. Some of us have gone the route of paying for external filtering. Others have gone the route of implementing their own front facing server/appliance to handle spam while leaving the light (and often redundant) work to the interworx system. What about us guys that want an effective anti-spam setup IN-HOUSE and on each individual server? While more spammers are using legit mail servers or at least ones that take into account greylisting, most do not. It seems there are no longer any working/effective greylisting systems available for qmail. (Before switching to iworx I ran policyd which is an extremely effective anti-spam device.) The sticky thing is that the iworx crew have no intention to ever leave qmail or to even provide the capability to support another mail daemon. I personally do believe this is a mistake. While, I do not have any crazy ideas such as thinking iworx will actually support a modern, still maintained and updated mail daemon, I do hope that some of my fellow iworx users can share some of their methods of dealing with the ever increasing tide of spam.
Will I have to resort to running a mail proxy and postfix/policyd (or similar solution) on each box to get the spam issue under control?
Perhaps someone knows of a decent open-source or fairly priced web e-mai mgmt interface along the lines of appriver, postini or barracuda networks which we can run ourselves?
This is as much a call to debate different points of view and technologies as it is a dim hope that it may influence future iworx development in some way. I mostly love iworx. I really don’t care for qmail and the b*stard it is. The majority of the net has moved on for obvious reasons maybe it is time iworx does the same.
For Iworx to support multiple email daemons doesn’t make sense business wise. That makes tracking down any bugs or even just random issues effecting a single server more difficult as well as other things I haven’t even thought of.
I think if the time comes that qmail isn’t running up to par and there is better alternative, Iworx will move in that direction.
I was hoping to start a constructive discussion. Many of us realize qmail isn’t particularly well suited for today’s realities. Neither is a spamassassin only solution. I’ve ran into a few issues with qmail, as I am sure, many others have as well. So, let’s be constructive here and not be defensive of the status quo.
Now, with that said I do love the iworx guys. Their support is top notch. But, they do seem to be pretty set in their ways, especially when it comes to using qmail. But, as I said, I don’t see them ever deciding to support a modern mail daemon. So, let’s see what we each do (other than paying an outside firm to handle spam) and see if we can’t come up with working suggestions for each other as well as the iworx team. I can honestly say the problems I’ve had with qmail I would have NEVER ran into with postfix. There are reasons for this other than configuration issues.
OK, with the disclaimer that I’m in no position to promise anything…
What would you recommend switching to? Keep in mind that the decision to change to another mailer daemon would be HUGE for InterWorx - we’d need to either just switch, which might be a nasty surprise and cause a lot of headaches, or support both at the same time, which would be a major complication for our development process. Neither is impossible, mind you, but both present some business challenges in addition to the more obvious technical ones.
One of our constant development challenges is to introduce new features without wrecking the old ones. Sometimes, it’s important enough to merit a change in behavior, and sometimes the risk is too great. You are correct in observing that our current position on the subject is that the risk is too great, but it’s certainly not just because we’re set in our ways
It’s more a pragmatic fear of waking up one morning to 1000s of tickets saying “oh no, you broke my email!” The responsibility of maintaining 1000s of servers and tens or hundreds of thousands of domains is one we take very seriously.
OK, I just re-read this - and it sounds a bit whiny. Not my intention. I just wanted to make it plain that we’re not deaf to the problem - we just need to balance solving this issue with the risk of causing more.
In response to your actual question - at InterWorx, we use a Barracuda, and I know that some of our larger customers do also.
I would just like to say this, we shut down SpamAssassin on our servers some time ago as it was putting to much of a load filtering out all the garbage. Another reason since the majority of our customers have a hard enough time clicking on the ON button to turn on their computer, asking them to set up all the parameters in SpamAssassin just wasn’t going over very well.
Thus we decided to move to a third party solution. And for the most part all our clients like it and the service has been pretty much trouble free.
But I have to say, mail is starting to become a specialty, the amount of resources and man power to run an effective email service is growing everyday. The time and effort for the ROI is getting to the point of not being worth offering email in a shared environment. I see a trend of providers making email with hosting a upgrade premium service in the future…heck some are doing today.
The sticky thing is that the iworx crew have no intention to ever leave qmail or to even provide the capability to support another mail daemon
Switching MTAs is not a simple matter. We’re not opposed to the idea, but you’re right, we’re not in any rush either. qmail has served us pretty well over the years, and it’s not like there’s any compatible “drop in replacement” - it’d be a lot of work to port all the existing interworx e-mail features to a new MTA.
While, I do not have any crazy ideas such as thinking iworx will actually support a modern, still maintained and updated mail daemon,
You almost made it without an inflammatory comment Needless to say I take issue with this comment. If qmail wasn’t ever updated we wouldn’t be able to provide SMTP-Auth, TLS support, SMTP-Level invalid receipient rejection, among other things. The fact is qmail is supported, maintained, and extended via patches from a very competent user community.
The majority of the net has moved on for obvious reasons…
Citations for this claim would be legtimately appreciated. Thanks for getting the discussion going
Needless to say I take issue with this comment. If qmail wasn’t ever updated we wouldn’t be able to provide SMTP-Auth, TLS support, SMTP-Level invalid receipient rejection, among other things. The fact is qmail is supported, maintained, and extended via patches from a very competent user community.