Author: Vic Date: To: hampshire Subject: Re: [Hampshire] Re: TRYING to set up my own simple mail server?
Can anyone help?
> <rant> > Why do people insist on using SMTP to send "big attachments" - there
> are far more effective and reliable mechanisms available, such as ftp
> to do this.
> </rant>
Indeed. I use a groupware system internally, whcih has a Document
Management system on it. Stick the big docs in there, and they're managed
and visible to appropriate users without all the tedious mucking around in
SMTP...
> Not sure I follow you here. The only thing you are using the ISP for
> is *sending* email from your own domain. They're not receiving your
> email, and we assume you won't be sending spam or abusing the system.
With a dynamic IP address like this, there might be a need to smarthost
outgoing mail. This is certainly far from ideal, but a number of MTAs
won't accept mail from anything they think might be a residential
connection. Smarthosting is trivial in sendmail - I assume it will be
suitably covered both in postfix and in exim.
>> It is necessary for the
>> individuals to be able to get their email via web interface such as
>> squirrelmail and outlook would be welcome too if possible.
>
> Beware outlook / entourage. They have significant problems with
> handling secure SMTP.
Indeed. Personally, I wouldn't permit Lookout access except from the local
LAN or by VPN.
> As a general rule of thumb, avoid example/bogus information unless it
> is truly a requirement for privacy / security.
I wouldn't even use that qualifier - if your security relies on hiding a
domain name, then that is "security by obscurity" - and that is no
security at all.
>> and update the hosts file
>> to include mail.jmbit.co.uk pointing to its internal IP as well?
>
> Not strictly, if DNS knows about mail.jmbit.co.uk.
Indeed, using a hosts file for this gives you difficulties with scaling
and maintenance - 2 years down the line, you buy a new machine, and it
just won't see the mail server...
Bind 9 does a fabulous job as a DNS server, with separate views permitted
for any class of client you may care to specify. It makes much more sense
than trying to cobble together hosts files all the time.
> Secondly, you appear not to have a backup MX.
This is my only real disagreement with your post - for this scale of
operation, I really don't think there *should* be a backup MX.
A backup MX won't get the mail delivered to final recipients any faster -
they won't be polling it, and they might not have access to it anyway.
what it will do is to create a false sense that mail has been delivered -
when in reality it's sat in the backup's spool.
You also need to couple the two MXes quite tightly; if the backup accepts
mail that can't be delivered, you either need to drop it (with the risk of
losing mail with typos in the address), bounce it (and become a
backscatter attackvector), or forward it to someone for manual processing.
All of these are a problem.
The effect of not having a backup MX is that mail will sit in the sender's
spool for a few days. They will probably get a non-delivery warning after
4 hours. All these things are the next best thing to actually delivering
the mail...
> If your mailserver dies, you may
> lose mail, you will lose time, and cause your company considerable
> pain.
You will lose time, you will lose access - but you shouldn't actually lose
any mail.
> Do you plan to offer any service guarantees? If this is a
> commercial company, you're setting yourself up for a support headache,
If this is a line-of-business machine. there needs to be a DR plan, the
same as any other LOB machine. With mailservers, that's unlikely to be a
huge issue (although you might lose some Bayes data if you have a major
crash - so life will get a bit spammier...)
> I'd suggest you have a chat with whoever hold the budget for this
> project, and establish what sort of service agreement they expect.
> They will expect something, even if it is implicit.
Not only is that true, it's also something that rarely gets discussed
until there is a problem. At that point, many people want 24/7 cover with
a 1-hour response time, and all for one beer a year :-(
> You could also consider finding someone / some company
> who will help you set this up, but provide training and documentation.
> That shares the load, and may get you a more reliable solution. It
> also means you get to learn "on-the-job" from someone who's done it
> lots of times before.
I should probably add a disclaimer here: that's now my day job...
