Karanbir Singh wrote:
Christopher Chan wrote:
I am sorry but I do not share that view for incoming mail. The latency
in getting the mail replicated probably is longer than it takes to do
the actually delivery to the mail store.
I am not sure what you mean by the word 'replication' but in most cases
the user mail stores are on the same shared block device. And I've
worked with an ISP recently that deliver between 12 to 16 million emails
per day and dont have this problem of 'latency in replication'. Using
exim and cyrus-imapd over 2 user facing nodes.
I thought we were talking about the queues? I agree and did say that the
mail store should be on a distributed filesystem.
Besides, as John already pointed out, emails in the spools can hang
around for days. I believe most MTA's only discard completely after
7days of non delivery.
That default setting is no longer applicable today. Users will scream
if they find out that their mails have been sitting in the queue for a
day.
Mail will wait with a delay if there is a problem with the remote end
receiving the emails. Users will screan much more if they find that
their emails are just going into /dev/null and they are having to work
the retry mechanism by hand rather than their email server. Besides, if
I send an email at 2am and there was a network outage at the remote end,
its nice to know that
Some people would rather be informed that their email was not delivered
within the hour and I do not see how not putting the queue on a shared
network block device would lead to emails going into /dev/null.
Obviously I would recommend at least raid1 for the local block device.
For today's businesses, one day can make or break a deal and so email,
being a much faster form of communication than snail mail, has come to
be seen as the preferred choice. People start calling when they know
they are supposed to get an email in a minute or so when it does
materialize.
Your point is well made, however - email does normally go in a single
stream. Its when there is a problem and a retry mechanism hasto kick in
that there is a problem. Its only the crazy goons who develop MS
Exchange who havent got their head around this problem, something solved
by the general internet users about 25 years back.
You have lost me here. Besides the shoddy implementation of Exchange,
especially in earlier versions, what about Exchange and its retry
mechanism?
He is welcome to replicate the queue. His traffic levels will be so
low that it really does not affect things but if he is using qmail I
hope that the filesystem is completely identical on the secondary.
I personally hate qmail, its place is back in the 1990's - perhaps in
the 1980's. But that is a pure personal opinion. I know there are plenty
of people, some whom I even respect technically, who still use it :/
Yeah, I would not put an unpatched qmail on a MX nor do I feel like
patching one. I use postfix with vpopmail instead notwithstanding
vpopmailś deep links with qmail.
Also, you seem confused about the filesystem on the secondary. Its not a
different filesystem - its the same shared block device exposed to both
machines. if the primary fails, its the same system that the secondy
see's when its made live. the DRBD packages are included in CentOS - you
should give it a try. One easy way to do this is setup 2 VM's and have a
play there. its quite cool.
Okay, Les helped me with that one. RAID1 on the network. So you would
have to use GFS or something like that with it and have the service down
on the secondary unless it was sendmail you were running. Pretty much
what I said except that I was not too sure with how DRBD works since I
have heard about stuff like this that replicated on the hour or something.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
