Neils, the question is, why is it so hard to set up your own mail server and
have it basically do what you need?
Ted, you keep saying things like this as if they are true. Simply put, they're
not. The obvious counterexample is MS Exchange, which, my personal dislike for
it notwithstanding, is hardly rocket science to install and configure. Lots of
people with very modest technical skills do it routinely. (The place where they
get into trouble is when they outgrow what they originally did, have to upgrade
the hardware, etc. This is where things can get to be a bit of a PITA with MS
Exchange.)
In fact it's the existence of MS Exchange that keeps a lot of vendors from
bothering with this space. (It's absolutely why we started moving away from it
~15 years ago.) Even so, there are other offerings, such as the server IETF
participant Hector Santos works on. Perhaps he can comment on how
straightforward his product is to set up.
Now, of course if you insist whatever obscure flavor of Linux floats your boat,
and then insist on using pure open source and compiling it from scratch, which
then more or less means different software for the store, MTA, and AS/AV, and
then decide you want to twirl a bunch of knobs because they look interesting
and you might need them, then you have opted for an approach that's going to
take some time.
Heck, our software isn't targeted for this market segment, but set up is
basically download and run the messaging/directory server installer, run a
single configuration script that only asks a handful of simple questions,
install your certificate(s) for SSL/TLS, and finally hook in whatever AS/AV
solution you're using. (The last step typically consists of around five
commands in our configuration utility.) At this point you'll have a
full-function server set up for a single domain offering SMTP, SUBMIT, POP, and
IMAP. You'll then need to add the accounts you want using the LDAP tool of your
choice, or alternately you can install the provisioning tools, but that's
almost certainly overkill for a small setup with only a handful of accounts.
And yes, there's one of those nasty configuration files underneath it all, but
you never edit directly. It's all done through a management interface. The
template the initial configuration generator for it is only 310 lines long, and
a lot of that is comments, boilerplate, and XML cruft.
Frankly, these days the problem isn't setting things up, it's ongoing
maintenance. What's your backup strategy going to be? What's your approach for
monitoring store disk space and the MTA queues going to be? When our customers
call in the odds are it's going to be a maintenance or performance issue, not a
"I need to reconfigure" issue.
Is it because it's really that hard, or is it because the right tools don't
exist, or the problem hasn't been properly reduced to practice? I think it's
more the latter than the former. It sounds like Postfix has improved since I
last did a Postfix configuration, but it's still got too many knobs, because
it
addresses too many disjoint use cases.
Sigh. The existence of knobs does not imply that you have to turn them or even
know what they do. Our product has literally thousands of configuration
settings, but the way it's designed you don't even know they're there unless
you're using them. And if you're running a simple single host setup it's
unlikely that you'd ever need much more than the default configuration. But if
you do need them, there's extensive documentation on them all, as well as
technical support.
And it looks like mailpile is starting
to wrestle with the identity problem in a useful way, and there is other
interesting work going on in the usability/identity/security areas, but I'm
not
hearing people here talk about how that's being worked on in the IETF. I
would hate to see a bunch of ad-hoc protocols with no spec and no interop.
Since I categorically reject your thesis that initial setup of a simple mail
server is the Hurculean task you claim it is, I have no idea what work the IETF
could undertake to solve this nonexistent problem.
Ned