What would it take you to switch SMTP servers?

on Haraka

Matt

So I currently have 125 people on github following Haraka as a project. That’s amazingly great for such a new project that doesn’t really have what I might call “mass nerd appeal” (such as for example node for the iPhone, which relatively few people will ever use for anything useful, but got massive numbers of followers almost immediately). However of those 125, I have heard from only 1 person that they intend to use Haraka for a real project. Now there might be 124 sleeper projects out there, who knows. I do remember from my earlier days running open source projects that you needed more than 300 people on a mailing list to make it “active” – which basically means you have a lurker to poster ratio of almost 100:1. So the question, for those of you out there running SMTP servers in various organisations, is what would it take you to want to switch SMTP servers to something new? What feature is missing? What would you love to be able to show management about how well you did?

David Thornton

that's easy: good docs, easy to use and configure, modularity, speed, interoperability (play nice with apis) , scalability, vendor support ( are there rpms?) and of course it's got to be shiny ( i.e. have tuns of buzzword appeal: dkim , spf , greylisting, spear fishing , grey whalling, hadoop, cassandra, and fruit flans).

David Thornton

Hold on , I did some reading and it looks like if I want your mail server to do stuff I have to tell it to do it, like say receive email. Shouldn't it do that by default (within some reasonable bounds)?

David Thornton

The more I read the more it looks like this is a tinkerer's mail server. But I can see how this could be very valueable to be able to rewrite the flow of your mail through your "integration" easily and quick. plugin based, hook based, a bit like ecelerity?

Steve Atkins

Having written a couple, and having had hideous interoperability issues pop up even after three or four years in the field, my primary concern is for battle-tested interoperability (which is a fair bit trickier than just 100% 5321 compliance). Secondary requirements split into two, depending on whether I'm looking for a generic mailserver or a "stunt" mailserver. The former, I'm looking for something robust and configurable, such as postfix or exim, The latter, something where I can easily inject code at transaction time - qpsmtpd or, perhaps, haraka. They're very different things, though, and I wouldn't consider using qpsmtpd for my main mailbox.

Matt Sergeant

Steve: Yeah I kind of agree about being battle tested for certain things - especially inbound delivery - there is no spec for it, no standard for it, so you're really best off leaving that to a current mail server that knows what to do with the mail on your system. I'd be interested to know what your interop issues were, if you can remember.