On 25/05/12 14:43, Paul Stimpson wrote: and once more including the list... dang reply-to. :) Questions... 1. what is your VPS running? 2. are you only providing mail for yourself, or many others? in any case, my personal preferences are (and these are running on my VPS) postfix for SMTP [along with amavisd + clamav + postgrey + spamassassin] dovecot for IMAP both of these use an openldap backend for authentication and virtual accounts. roundcube for webmail. It's pretty and functional. Stuart -- Stuart Sears RHCA etc. "It's today!" said Piglet. "My favourite day," said Pooh.

Hi, Good work! It's great that you're jumping in the deep end. I'd recommend Olaf Kirch's "Network Administrator's Guide" http://www.amazon.com/Linux-Network-Administrators-Guide-Kirch/dp/1565920872 http://oreilly.com/openbook/linag2/book/index.html It's almost positively ancient: the first few chapters are especially dated but it'll give you a really, really solid grounding in very general network admin concepts. It'll allow you to get some idea about the things you don't know you don't know. It'll enable you to know the correct questions to ask. This is ambitious: I wouldn't try to do everything all at once. Pick the most important thing and then try to get that up and running. I'd hesitate to recommend picking the "easiest" thing because you won't know which one that is until you've done them all and no one else will be able to tell you because it depends heavily on your background and interest areas. Most of the services can be implemented on their own and then integrated into a larger whole later on. What you're describing above divides nicely into the traditional "MXA" mail roles. Incoming Mail : Mail Transport Agent POP3/IMAP: Mail Storage Agent SMTP for sending: Mail Submission Agent Webmail: Mail User Agent There are various guides around that explain these concepts and, again, the older ones tend to give you a more solid grounding in the core concepts and the newer ones are much more product and distro specific. I was going to give you a grab bag of links from my bookmarks but it turns out that the ones I have on this machine are woefully incomplete. Allow a good afternoon for research of each of these topics and then another afternoon of installation and configuration. I'll tell you what I use and why: I use BIND to host my DNS. BIND has an interesting track record and a lot of the things you hear (both good and bad) apply to versions 4.9 and 8. 9 is a whole different thing (with it's own good and badness). All the nameservers have their pros and cons. You could alternatively look at PowerDNS or djbdns. I'm sure there are others as well. In the first instance I'd recommend using your registrar's servers for your domain (say, example.net) and then delegating a subdomain to your server for messing around with (say, fiddling.example.net). If you can do that then you're half of the way there as far as infrastructure (deploying nameservers, delegation points, glue, caching, slaves, AXFR, IXFR, administrivia, etc) goes and you haven't broken anything for your main domain. As well as infrastructure you've got to consider the names themselves. For delegation you'll need to understand NS and SOA records. In order to give names to IP addresses you'll need to understand A records (ignore IPv6 for now). In order to deploy mail you'll need to understand MX and PTR records. If you want to deploy antispam measures such as SPF you'll have to understand how they use TXT records. You'll also want to understand TTL for both cachable results and NXDOMAIN results. Be familiar with the client side testing tools such as dig, host and nslookup. You can get familiar with them on other peoples' domain and then compare them to what your own domain produces. There are also various "looking glass" and sanity checking services on the web that will tell you interesting things about how your DNS appears to be configured from their point of view. You can deploy everything for your mail infrastructure without having to deploy your own mailservers: your registrar's ones should be sufficient. http://www.shonky.com/Docs/dns.txt http://www.intodns.com/ http://dns.squish.net/ For this I use exim. The choice is usually between Sendmail, exim and postfix. Sendmail is the grand-daddy of MTA software. Postfix and exim are both mature replacements. I got on with exim because of its monolithic nature and anti-spam promises. exim is a single binary and can have a single configuration file. Postfix is split into several smaller tools and often has a swathe of configuration files. In reality, anti-spam is probably just as good with either but exim got there first and therefore has the reputation as "the anti-spam MTA". Popular opinion amongst the cool kids seems to be with Postfix, but I've never managed to ascertain any solid reasons why. Lots of important people use exim (University of Cambridge; where it was written, Debian and others). Configuring MTAs is *hard*. They have thousands of knobs and they are loads of different mail architectures to choose from. The exim documentation is a reasonably good read if you start at the beginning and have plenty of clues about the subject matter. You don't need to read it all tho'. Tony Finch at the University of Cambridge has a bunch of presentations and example config files that are worth a look. In the first instance I'd get something listening on port 25 and see if you can encourage it to forward mail to, say, a gmail address or something. That way you don't have to worry about mail storage, POP, IMAP, etc. It's really important here to use a "proper" desktop mail client to read the test messages: that way you can get a full "view source" and can inspect the mail headers to work out what's happening where. I managed to scrape through without too much other instrumentation or traffic sniffing but it can be a bit hairy. Having a sharp eye on /var/log/exim (tail -f /var/log/exim/*) is always worth it. Adding anti-spam measures can be easily accomplished by hooking your working MTA into the Bitfolk Spam Assassin service. For this I use Cyrus. Cyrus is "serious business" but I like it because it's a completely "sealed" mailserver. It doesn't require UNIX accounts for every user and it doesn't integrate tightly with the MTA: the MTA delivers mail over a local mail protocol and so the two pieces of software end up completely independent. Other options are Dovecot, Courier and uwimap and traditional mbox / Maildir spools. Cyrus has traditionally had a reputation of being a bit of a pig to set up. I set mine up in ~1996 and I've been happy with it ever since. I'm not sure how it compares to other MSAs currently in use but when I deployed one a few years ago it was fairly painless. Initially I used it as a standalone store: I just set it up as another account in my mail software and then dragged messages to it for archiving: my ISP provided my main INBOX. Once you get to that stage you can teach your MTA how to deliver mail to it directly. Watch out for Cyrus SASL. For this I use exim. The whole idea of separating mail sumbission services from general server-to-server mail transport services is relatively new. Running both personalities in a single MTA config requires quite a bit of attention to detail and can be quite annoying. Again, Tony Finch has some clues in his config files. If you choose exim for you submission service then it makes sense to choose it for your incoming service as well. Ditto for postfix. Alternatively you could use a dedicated submission agent such as msad for your submission service and still use exim or postfix as your MTA. You can find msad on http://kitten-technologies.co.uk/ Running a submission service is all about fixing up the headers that MUAs (Mail User Agents) produce incorrectly and adding the ones that they fail to produce at all. I chose roundcube for this because it looks snazzy and I thought that the users would like it. It's a bit of a pig to configure as it's a PHP app and therefore debugging options are limited. Once it's running then it works reasonably well and can hook into your Mail Store and Mail Submission agents. There are loads and loads of webmail projects out there and they range in complexity from webmail only all the way up to comprehensive webapp frameworks where the mail client is just a little component. In order to run webmail well you probably want to run a webserver with SSL and paid-for certificates. I used self-signed certificates because I'm cheap and it shows. I hope that this has been useful and hasn't overwhelmed you. Let us know how you get on an let me know if you have any other questions. Good luck. Regards, @ndy -- andyjpb(a)ashurst.eu.org http://www.ashurst.eu.org/ 0x7EBA75FF