Simon Jones wrote:
Here's the rpm query:
[EMAIL PROTECTED] ~]# rpm -qa | grep toaster
| sort
Hmm. All the packages seem like they're there, are they all running?
(qmailctl stat). If they are, you may want to change your tcp.smtp file
to read like the example i sent you. Right now you're not scanning
emails for spam/viruses without the simscan portion. You're also not
limiting the recipients by not having the chkuser options in there.
Obviously you don't HAVE to use them.
As for the backup mx:
The problem is that since the backup server will always accept mail for any
domains listed in its accepted relay file (so it WILL relay if the primary
goes down) I only want it to relay under these circumstances - reason being
that the backup can be used as a spam gateway for dictionary attacks even if
the primary is online, the relay server does not know if [EMAIL PROTECTED]
is a valid address, only the primary knows this because that is where the
account is specified.
Okay, I understand a little better now. The short answer is that unless
you move to a cluster-type setup there's no easy way to do this. I've
begun looking into modifying the Toaster package to a "cluster-toaster"
package, but this is a spare-time thing for me so it will be a while.
What I have done on my systems, (1 main MX, 1 or 2 backup MX's depending
on the domain) is this:
Set the queuelifetime of 10800 in the main MX (3 hours), and backup MX's
have a queuelifetime of the 7200 (2 hours).
Backup MX checks to see if Main MX is alive (bash script) every 45
seconds. If it is, continue as normal. If it's NOT, then the backup MX's
change their queuelifetime to 259200 (3 days) and reload qmail for the
change to take. This makes the backup MX's hold the emails for 3 days
while I get the main back up and running.
This serves 2 purposes - it keeps my queuelifetimes low in normal
operation, so mail bounces are processed in a timely manner (letting the
users know they misspelled a name or whatever within 3 hours), and gets
the spam that is stuck in queue out in a timely manner. If the main MX
goes down, it takes action to hold the emails for 3 days which gives me
plenty of time to either get the main server back online (or rebuilt) or
log into them and change the queuelifetime to a longer period of time if
it's needed.
Sure, spam gets stuck in the queue (my backup servers stay at a constant
50-60 messages in the queue), but they get dumped out in a timely manner
(2 hours). In the event the main MX is down, I'm not concerned with spam
at that time, honestly. The impact of the backup MX trying to deliver
those messages to the main MX is minuscule, so I don't worry about it.
The only real way to get around it would be to go with a clustering
system, like the one Bill Shupp outlined
(http://shupp.org/maps/ispcluster.html)
Hope that helps some.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
