Is there some reason you would want the secondary MX server not to be running at certain times? Seems simpler to me to just let them both process mail all the time. The secondary would simply queue up messages for the primary until the primary is available.
Of course, you do want spamdyke (and clamav and spamassassin) installed on the secondary server as well. Spammers are well aware that some secondary mail servers to not have anti-spam measures implemented, and intentionally target these hosts. On 07/10/2011 04:43 PM, Carlos Herrera Polo wrote: > Thanks, I understand the problem now.... > Another solution not "elegant" may be shutdown second server (MX) when > first server is UP, when first "crash" then switch on the backup smtp > for archiving email, the second SMTP server must be running spamdyke, > clamav and spamassassin too. > > > > 2011/7/10, Peter Palmreuther<li...@zentrumderarbeit.org>: >> Hello, >> >> On 07/10/2011 at 11:29pm Carlos Herrera Polo wrote: >>> >>> ---------- Forwarded message ---------- >>> From: Carlos Herrera Polo<carlos.herrerap...@gmail.com> >>> Date: Sun, 10 Jul 2011 16:25:59 -0500 >>> Subject: Spamdyke and smtp backup (in MX) >>> To: qmailtoaster-l...@qmailtoaster.com >>> >>> We need a second MX register en our domain, for smtp backup server.... >>> >>> In the first server (mx 10) we have qmailtoasker with spamdyke >>> (graylisting, rDNS check, etc). >>> In the second (mx 20) we have qmailtoaster without spamdyke..... It >>> forward emails to first server when this turn on. >>> >>> This is ok ? Or the spam mail will enter for the second MX server ? >> >> It's possible spam will be sent through secondary MX. >> Original sender IP based checks can't be performed when 2nd MX forwards >> the messages, so only sender email checks can be applied. >> But first this address can be easily forged, and second this would only >> load (by 1st MX) than rejected messages on 2nd MX, instead of (originally) >> sending MTA. >> >> And this can happen even if your 1st MX is up and running, 'cause nothing >> forbids a sending MTA to contact 2nd MX. MX "priority" is only a "hint" >> to the sender. >> A sending MTA could even interpret a temporary error, e.g. because of >> graylisting, as a reason to contact 2nd MX. >> >> So I'd set up MX 20 spamdyked as well, or regularly run a script there, >> that checks if MX 10 is unavailable and only than enables actually receiving >> messages. As soon as MX 10 is available (again) it should disable receiving >> of messages to MX 20. That way only during MX 10 downtime spam messages can >> be routed through MX 20, and not all the time. >> >> One way to achieve this "non receiving" could be to set up tcpserver to >> start a wrapper script instead of qmail-smtpd directly. >> This script could, depending on a "state providing file" either print out >> a temporary error messages to the connecting client (and exit), or 'exec' >> real smtpd process. >> >> HTH& regards, >> >> Peter >> _______________________________________________ >> spamdyke-users mailing list >> spamdyke-users@spamdyke.org >> http://www.spamdyke.org/mailman/listinfo/spamdyke-users >> > -- -Eric 'shubes' _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
