Hi,
> Thank you for you help with choosing a domain registrar. I went with
> Gandi I'm the end and they seem great.
>
> I've bought my first domains and I'm just about to begin configuring
> services on my VPS. This is the first time I've run a server facing the
> public internet.
Good work! It's great that you're jumping in the deep end.
> I'd really appreciate any guidance on the best way to set up the
> following so that it's competent, reliable and doesn't get pwned. I want
> to be a good net citizen.
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.
> *BIND
> *Incoming mail
> *A POP3/IMAP server for my client.
> *An SMTP server for my client to send to.
> *Webmail for on-the-road access to my mail. (my existing provider uses
> Open.Exchange and I like it but I'm also happy to consider other
> recommendations)
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:
> *BIND
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/
> *Incoming mail
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.
> *A POP3/IM
