Thanks Eric, but my problem is that not have another server for mx backup, I am using Synametrics Smtp Gateway - a free smtp server for windows.
I can't install a virtual machine with qmailtoaster (the server not is mine) 2011/7/17, Eric Shubert <e...@shubes.net>: > 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 > -- Enviado desde mi dispositivo móvil _______________________________________________ spamdyke-users mailing list spamdyke-users@spamdyke.org http://www.spamdyke.org/mailman/listinfo/spamdyke-users
