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.