On Mar 11, 2007, at 5:53 PM, Jeffrey Goldberg wrote:
On Mar 11, 2007, at 8:27 PM, jekillen wrote:
If you will allow me to break in on this exchange;
Does this advise [don't run your own direct to MX mail server] apply
if you have static ip service and are running web servers from these
addresses, with the ISP's blessing? (meaning you also have at least
two name servers running for the registered sites)
most or what you mention in the way of pluses and negatives
I am either aware of or have had some experience with, E.G.
I had someone attacking a machine I have one of my sites on
and the secondary DNS server. The site has .net as the top
level domain and I supposed that the attack was because some
one assumed I was using it to run a mail server. Anyhow I was
getting requests for "-" "-" so often that it was causing Apache
to run out of memory and kill processes. I caught it in process
and shut down and rebooted the machine. But to tell you the
truth, I am not sure if that was causing Apache to run out of
memory, it is just guilt by association. Since all this machine
really does is serve as my secondary DNS server I shut
down Apache, not really needing to have the site up at this
I am itching to get mail service running as it will perform some
important functions for my sites. But I have some serious
learning to do. Every bit of knowledgeable input helps and
this is a serious tutorial.
First let's separate questions. One is dealing with your own incoming
mail. The other is with sending mail out direct to MX. These two can
(and often should) be separated.
For the question of hosting your own MX there are positives and
negatives. Here is a list off of the top of my head. It is far from
(1) You get to fully control your rejection/acceptance policy from the
(2) You get the learn about running such a system.
(3) You dramatically reduce your lock-in with an ISP (who can change
email policy or practice at any time.
(4) You don't have to pay for some outside service (I use
hosting your incoming mail if you want something better than the
email service your ISP provides.
(a) You have to maintain what is really a surprisingly complex system
for such a simple protocol.
(b) You have to defend your system against attacks it otherwise
receive, including DoS attacks.
(c) Damage of being overwhelmed (either by deliberate attack or spam
may be harder to contain.
(d) Your system needs to fail appropriately. For example, if you use
something like LDAP to maintain username or email address
need to make sure that if your LDAP service fails your mail
in an appropriate way (say a complete shutdown) or issuing
rejections instead of in an inappropriately issuing 5xx for mail
would be accepted normally.
If (1) (or (2)) is really important to you, then go ahead. But
probably the best way to see whether (1) really matters is to ask
yourself what things you would like to do that you couldn't do unless
you ran your own MX. For example, if you have strong feelings about
whether DNSbls should be used prior to content filtering or as part of
it. Or whether you want spam and virus rejections to occur at SMTP
time or later. Whether you want SPF failures to generate immediate
rejections. Whether you want to make use of sophisticated IMAP
features that ISPs can't provide. If you don't have strong feelings
about these sorts of questions, then I doubt that (1) applies to you.
Now there is the second question about doing direct to MX for mail
sending instead of going through your ISP or some third party service.
(i) You control queing and retry rates.
(ii) For bulk mailing (mailing lists) there is an advantage of how
STMP session are organized.
(iii) You are not as dependent on your ISP or a third party for
mail out, if they are slow or unreliable with mail
(iv) If your ISP's mail server provide crappy bounce information and
need better information.
(v) If your ISP adds junk to your mail or sends out mail in
unfriendly so as
to get itself on blacklists or leads to other forms of needless
(vi) You get to learn about running such systems
(A) Even with a static IP address, your assigned address may look
to other servers who may then reject mail coming directly from
(B) Your ISP blocks/disallows this sort of thing (not a problem in
(C) The reverse DNS records for your IP need to correspond
to your domain name, otherwise lots of servers will reject mail
(D) You need to follow the RFCs and conventions strictly so that you
get yourself added to blacklists
(E) It is probably a little less network efficient for you to talk
to servers all over the planet when you could just talk to your
server which will be much closer to you.
Here again, if (vi) is your primary reason for wanting to run your own
direct to MX system, then use it just for one of your minor domains.
That way, if you mess up, you won't get your major domains
blacklisted. If (i) and (ii) really matter for you, then go ahead,
but I think that you should have a real reason beyond "I can,
therefore I ought" if it is going to be your primary way
of getting mail out.
In the end it is a matter of individual taste and need. With good DSL
or FiOS lines, along with a proper backup regime and Uninterruptible
Power Supply hosting your own website makes plenty of sense. But mail
is a tricker thing to maintain than apache, so my view remains that
unless you have some specific need for the kind of control you can get
by running your own, let someone else handle your mail transport to
the rest of the world.
I hope this helps. And keep in mind that different people will offer
different advise. I certainly believe my advise is good advise
(otherwise I wouldn't have offered it), but I'm also aware that I
could well be wrong.
Jeffrey Goldberg http://www.goldmark.org/jeff/
email@example.com mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"