Slashdot Mirror


E-Mail Server Setup Advice?

dhammala asks: "I am responsible for setting up and maintaining a mail server for small web-hosting type business. We currently host about 75 domains, around 100 mailboxes and due to the efforts of our sales team, we are wanting to get ready for some great increases in those numbers. I am worried about my current configuration and ease of administration. More importantly (well, at least to the customers) is email deliverability -- it seems that messages delivered to some big players are being marked as SPAM or disappearing altogether. I am asking the Slashdot community for it's insight and advise on 1) if my current choice of software/configuration is a good match for this situation and 2) if there any additional measures I might take to ensure email deliverability?" "Here is an overview of our current setup:
  • We lease servers at ev1servers.net.
  • The servers are running RHEL ES3.
  • We chose to use Postfix and have it configured to support virtual users and domains mapped in MySQL tables. The reference I used to configure this setup is located here. We initially chose Postfix over qmail because it was open and over sendmail because the config files are actually readable.
  • I have added in SQLGrey grey-listing for Postfix to provide a simple level of SPAM detection for our users. We are not wanting to deal with the customer service and higher box loads of mail scanning at this time. We might choose to use a 3rd party vendor to do this as needed.
  • Messages are delivered locally via maildrop in maildir format.
  • Courier IMAP is running to support both IMAP and POP access to the mailboxes.
  • Postfix Admin was setup for easy mailbox administration.
For deliverabilty, I have/am taking the following steps:
  • I have verified that our reverse IP records are correct
  • I have created SPF records for all of the domains
  • I have verified that our server is not listed in any blacklists (great scanner at dnsstuff.com)
  • I have started to install DomainKeys for Postfix
In doing all of that, I have found that our IP is listed in the BlarsBL. Do I need to be concerned about this rogue list? The IP was there before I even began to setup the box.

I have not yet been able to get DomainKeys to work with Postfix. It was during my configuration attempts that I started to question this setup and wondered if this was the best setup for our situation.. this inquiry has lead to this posting.

In a perfect world, I would have an email server that:
  • is easy to administer,
  • supports automated mailbox setup/removal (currently I can just insert rows into my tables and the mailbox setup is done)
  • supports current technologies, like grey-listing, DomainKeys, etc
  • is secure
  • makes the best use of system resources -- I want to get the 'best bang for the buck'
So what do you think? If I stick with this setup will life be grand? I am open to something new AND even taking the time to learn a new setup. If I do need to switch to something different, my only concern would be the ability to migrate existing mailboxes and messages over to the new setup.

Are there any other technologies or configurations that I need to implement to support the best deliverabilty rates?"

2 of 67 comments (clear)

  1. Blame by Anonymous Coward · · Score: 0, Interesting

    You do realize that when something breaks or is misconfigured or *you* do something wrong and it affects your coworkers or your customers - you will take full blame, right? You're not going to have th ability to call one person that will support you and fix you and take the blame for anything that went wrong?

    Not only that, but with so many different groups involved in your email solution, just getting good support even in the community will be hard to do. It's not like there's any QA done between X and Y and Z on A and B hardware and C environments.

    Not to mention, nobody is obligated to help you out in a certain timeline (say, you may or may not ever get an answer rather than getting an answer and help from someone live within an hour).

    Sometimes you get what you pay for. And in big-business email centers - it's such a case.

    Personally, I use postfix and qpopper and spamassassin, but I'm also not providing email for a hundred or a few thousand customers.

  2. to the original poster, my personal opinion by Kalzus · · Score: 2, Interesting

    If I were you, I would ask myself at least this:

    "If the building the server lives in falls into the center of the earth, but my boss wants the mail back up (not necessarily with their data, just live again), would I be able to put Postfix, SQLGrey, LDAP auth and Courier back together in less than 4 hours except for user accounts?"

    If you are sufficiently detailed enough to pull that off within 4 hours except for user accounts, you probably have the bits you need to wing all the rest of the bells and whistles (webmail, MAPI integration, upgrading one piece and making sure the other 11 don't die, etc.) which eat up your time.

    The main problem with going commercial (which you should consider if you're sure it'd take you at least 8 or 9 hours of a day to put this together from zero) is that the extra features (Outlook integration via MAPI, etc.) tend to cost.

    OTOH, if you go commercial the extra features are not yet another thing you need to spend time on because presumably you're paying for parts that already work.

    Choosing a path starts with your honest appraisal of your own skills.

    (Personally, I find Postfix + SQLGrey + Postfix virtual delivery agent to rock. But I don't mind going into the guts to add a new user or set a quota on an abuser or whatever. QMail I've found to be a tad dangerous. Often the slightest typo either puts qmail-send in a mad CPU loop (which is annoying) or delivers it in the wrong place (which is really annoying) or 5xx's it (bad). Adding extra steps into the qmail handling pipeline is a nightmare and should never be done on a production box first. But maybe I suck.)

    --
    "The Devil does not know a lot because He's the Devil, He knows a lot because he's old." -- unknown