Re: Backup MX server
On Thursday 02 March 2006 09:03, you wrote: Really? So when the box goes down, just let the mail bounce? Mail will not start to bounce the moment your box goes down. SMTP was designed to be reliable. How would it break spamassassin (which is what I use)? It doesn't. --- Lars Hansson
Re: Backup MX server
On Thursday 02 March 2006 15:14, Tobias Weingartner wrote: If the client can't find any DNS information on the destination, it tends to bounce. At least in all non-broken MTAs. Try it. Send email to [EMAIL PROTECTED] and see what happens. This was 1/2 his argument. No DNS info means no DNS info. Not somewhere out there (sung like the song) we have a cache... That's a different case though. foobar-toogood.com does not exist (NXDOMAIN) which is entirely different from a domain that exists but the nameservers are down or otherwise unreachable. The first case will cause immediate bounces, the second will only bounce after the sending MTA has retried for about a week. Only fundamentally broken MTA's will bounce immediately if namelookups timeout. --- Lars Hansson
Re: Backup MX server
Rod == Rod Whitworth [EMAIL PROTECTED] writes: Rod As a result spammers target secondaries strongly in preference to Rod primaries. As a project I listed a secondary for a server I support Rod using an alias on the same machine. All of the mail sent to the Rod secondary address (unless I missed one or two) was spam. Only about 60% Rod directed to the primary was spam. $ host -t mx stonehenge.com stonehenge.com mail is handled by 666 spamtrap.stonehenge.com. stonehenge.com mail is handled by 5 blue.stonehenge.com. Any mail delivered to spamtrap gets the following response: 450 Violation of RFC2821 Section 5 Paragraph 8 correlates highly with spamming and is therefore rejected. And yes, that's the paragraph that says deliver to lowest MX first. I'm skipping about *half* of the incoming spam just with this one trick. For more details, find the PDF I wrote titled you had me at HELO via google. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Backup MX server
NO - it does not! Well, not unless the sending MTA is broken. To quote from Postfix documentation referring to not getting an MX record from DNS: By default, the Postfix SMTP client defers delivery and tries again after some delay. This behavior is required by the SMTP standard. Yes it does. I've run an ISP with about 3000 accounts and currently manage the spam filter and virus filter for the campus here with about 20,000 accounts, so I have had plenty of opportunity to see this happen. There are many broken clients and MTAs out there. G
Re: Backup MX server
$ host -t mx stonehenge.com stonehenge.com mail is handled by 666 spamtrap.stonehenge.com. stonehenge.com mail is handled by 5 blue.stonehenge.com. Any mail delivered to spamtrap gets the following response: 450 Violation of RFC2821 Section 5 Paragraph 8 correlates highly with spamming and is therefore rejected. And yes, that's the paragraph that says deliver to lowest MX first. I'm skipping about *half* of the incoming spam just with this one trick. For more details, find the PDF I wrote titled you had me at HELO via google. Ouch! You're a brave one. That's fine until your first big network outage :-) Oh wait - I bet they're both on the same net segment, right? You wouldn't dare do that with a machine elsewhere on the net! I might use the fact that mail had been delivered to a backup MX as *one* factor in a spam evaluation function but rejecting it all entirely is pretty risky. I think you've just been lucky so far. Doesn't your main machine ever reject calls because the load average is too high, for example? I bet you're not running greylisting either. If you were, legitimate mail would frequently try your backup MX. It's a neat observation that several of us have made, and it is tempting to find a way to take advantage of it, but I think that rejecting *everything* that arrives on your lowest-valued MX is just going too far! Graham
Re: Backup MX server
On 2006/03/02 08:16, Graham Toal wrote: Any mail delivered to spamtrap gets the following response: 450 Violation of RFC2821 Section 5 Paragraph 8 correlates highly with spamming and is therefore rejected. Ouch! You're a brave one. That's fine until your first big network outage :-) Oh wait - I bet they're both on the same net segment, right? You wouldn't dare do that with a machine elsewhere on the net! eh? 4xx is tempfail.
Re: Backup MX server
Graham == Graham Toal [EMAIL PROTECTED] writes: Graham Ouch! You're a brave one. That's fine until your first big network outage :-) Graham Oh wait - I bet they're both on the same net segment, right? You wouldn't Graham dare do that with a machine elsewhere on the net! No, they're both on the same machine! I told postfix to listen to two specific addresses instead of 255.255.255.255, each with their own config file. It's a simple but elegant solution. Also, the 450 merely says (to legit senders) try again. So on the bizarre chance that my blue listener is down and it gets rolled to spamtrap, the sender will retry in a half hour or so. Graham I might use the fact that mail had been delivered to a backup MX as Graham *one* factor in a spam evaluation function but rejecting it all Graham entirely is pretty risky. I think you've just been lucky so far. Graham Doesn't your main machine ever reject calls because the load average Graham is too high, for example? As I said, it's *one* machine for both listeners. Graham I bet you're not running greylisting either. If you were, legitimate Graham mail would frequently try your backup MX. It's a neat observation that Graham several of us have made, and it is tempting to find a way to take Graham advantage of it, but I think that rejecting *everything* that arrives Graham on your lowest-valued MX is just going too far! I hate greylisting. It hurts legit mail to solve the spam problem. And I don't need it, based on the amount of spam I can kill with this (and a few other tricks described in the referenced paper). -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Backup MX server
On 02/03/06, Graham Toal [EMAIL PROTECTED] wrote: Personally I do believe in Backup MX, as long as it does proper relay checking. It's nice if it also does spam checking, but not critical because your primary MX will still do that. However Do you know just how disturbing it is to receive bounces for emails one does not send? FYI, spamcop happily accepts mail bounces as spam. And be sure, I do report these bounces for my domains with 'v=spf1 a mx -all'. Cheers, Constantine.
Re: Backup MX server
On 02/03/06, Graham Toal [EMAIL PROTECTED] wrote: $ host -t mx stonehenge.com stonehenge.com mail is handled by 666 spamtrap.stonehenge.com. stonehenge.com mail is handled by 5 blue.stonehenge.com. Any mail delivered to spamtrap gets the following response: 450 Violation of RFC2821 Section 5 Paragraph 8 correlates highly with spamming and is therefore rejected. And yes, that's the paragraph that says deliver to lowest MX first. I'm skipping about *half* of the incoming spam just with this one trick. For more details, find the PDF I wrote titled you had me at HELO via google. Ouch! You're a brave one. That's fine until your first big network outage :-) Oh wait - I bet they're both on the same net segment, right? You wouldn't dare do that with a machine elsewhere on the net! I might use the fact that mail had been delivered to a backup MX as *one* factor in a spam evaluation function but rejecting it all entirely is pretty risky. I think you've just been lucky so far. Doesn't your main machine ever reject calls because the load average is too high, for example? I bet you're not running greylisting either. If you were, legitimate mail would frequently try your backup MX. It's a neat observation that several of us have made, and it is tempting to find a way to take advantage of it, but I think that rejecting *everything* that arrives on your lowest-valued MX is just going too far! Graham, You seem to have some contradicting views on the matter. What is the difference between greylisting and the aforementioned spamtrapping approach? Isn't it essentially a variation of the very same thing, namely the use of 450/451 smtp error codes so that the broken MTAs can go and relax? :-) Cheers, Constantine.
Re: Backup MX server
On 02 Mar 2006 06:54:45 -0800 merlyn@stonehenge.com (Randal L. Schwartz) wrote: I hate greylisting. It hurts legit mail to solve the spam problem. And I don't need it, based on the amount of spam I can kill with this (and a few other tricks described in the referenced paper). If you used spamd for greylisting, you can make your pf redirect rule only redirect to spamd for windows machines. This seriously cuts down on delayed incoming mail since so many real mail servers are unix machines, and still catches all the spam zombie windows machines. Adam
Re: Backup MX server
On Thu, Mar 02, 2006 at 03:38:09PM +, Constantine A. Murenin wrote: Graham, You seem to have some contradicting views on the matter. What is the difference between greylisting and the aforementioned spamtrapping approach? Isn't it essentially a variation of the very same thing, namely the use of 450/451 smtp error codes so that the broken MTAs can go and relax? :-) Greylisting (which I use) defers (almost) all incoming mail for a period of time. His trick (which is awesome) only defers mail when his primary MX is down anyway or the sender is misbehaving by going to a higher preffed MX. I may have to add this to the arsenal. Nice one, Graham.
Re: Backup MX server
On 02/03/06, David Terrell [EMAIL PROTECTED] wrote: On Thu, Mar 02, 2006 at 03:38:09PM +, Constantine A. Murenin wrote: Graham, You seem to have some contradicting views on the matter. What is the difference between greylisting and the aforementioned spamtrapping approach? Isn't it essentially a variation of the very same thing, namely the use of 450/451 smtp error codes so that the broken MTAs can go and relax? :-) Greylisting (which I use) defers (almost) all incoming mail for a period of time. His trick (which is awesome) only defers mail when his primary MX is down anyway or the sender is misbehaving by going to a higher preffed MX. I may have to add this to the arsenal. Nice one, Graham. Correction: this very neat trick is by Randal L. Schwartz; Graham was the one opposing it in this thread. :-) Here are some results of 'You Had Me at HELO': http://fas.sfu.ca/Members/hebron/oscon2005/spam_session/document_view Cheers, Constantine.
Re: Backup MX server
Wouldn't a even simpler solution be to define a high MX record to a dummy address that would never answer. The spammers were going to retry, they would anyway and a real server would retry for sure.
Re: Backup MX server
Constantine == Constantine A Murenin [EMAIL PROTECTED] writes: Constantine Correction: this very neat trick is by Randal L. Schwartz; Graham Constantine was the one opposing it in this thread. :-) Constantine Here are some results of 'You Had Me at HELO': Constantine http://fas.sfu.ca/Members/hebron/oscon2005/spam_session/document_view Here's the actual link to the talk: URL:http://www.stonehenge.com/merlyn/Pictures/Trips/2004/04-09-DragonCon/HELO.pdf That might actually be an older version. I need to find the current version and upload it somewhere. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Backup MX server
Peter == Peter Fraser [EMAIL PROTECTED] writes: Peter Wouldn't a even simpler solution be to define a Peter high MX record to a dummy address that would never Peter answer. The spammers were going to retry, they would Peter anyway and a real server would retry for sure. My understanding is that the most popular spam delivery agents simply scan downward in the MX values until they can connect once, and then go on to the next domain. The error return doesn't matter to them... they're trying for as many different domains as possible, and once having delivered the message (even a 4xx), they move on. Thus, you need something that will at least connect and try to accept the message. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 merlyn@stonehenge.com URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Backup MX server
On Thu, 02 Mar 2006 00:14:29 -0700, Tobias Weingartner wrote: On Thursday, March 2, Rod.. Whitworth wrote: On Wed, 01 Mar 2006 23:16:59 -0600, Graham Toal wrote: If your DNS is on the same net as the mailer, its down too. Senders soon get no result at all when they look you up, with the result that mail *bounces* (unknown address) rather than requeues. NO - it does not! Well, not unless the sending MTA is broken. To quote from Postfix documentation referring to not getting an MX record from DNS: By default, the Postfix SMTP client defers delivery and tries again after some delay. This behavior is required by the SMTP standard. If the client can't find any DNS information on the destination, it tends to bounce. At least in all non-broken MTAs. Try it. Send email to [EMAIL PROTECTED] and see what happens. Lars answered that with precision. RFC2821 says that a sending MTA MUST retry in cases where the failure is possibly caused by temporary failure. There is a difference between a failure to connect to an authoritative DNS and getting a response that says the domain does not exist. It also neglects the fact that lots of caching nameservers elsewhere will have a copy of the records that likely will not expire for quite sometime. I know mine are set to 3600 but I have had the sad experience of changing a domain from one dns hosting service to another and the old one had a TTL good for a week. This was 1/2 his argument. No DNS info means no DNS info. Not somewhere out there (sung like the song) we have a cache... Note that 5 days of pent-up mail arriving at once can kill a machine even if it is normally up to the peak loads you get, so you want a throttling control both on what the backup MX forwards to you when you return, and what you accept from other sources when you return. 5 days of pent up mail will NOT all arrive at once. Not all of the senders will try again simultaneously and it is also likely that each of them will also not even flush all of the delayed messages in one batch. Rate limiting in decent MTAs mitigates the problem. It most certainly will if the backup MTA sends it all at once. And if you read what you responded to, he said make sure that the backups to rate limiting. And you respond with Rate lmiting in decent MTAs mitigates the problem. So? Why are you saying what you are saying? Whoops! What I slipped up on there was deleting the line that said: If you don't use a backup/secondary MX then you will find that prior to the 5 days line. That said, having backup DNS located elsewhere is never harmful as long as you can get it updated as fast as your master in house. scp, rsync, etc, etc. It will tend to get updated faster than the primary, considering you've got to edit the primiry's version by hand (usually). It may be faster but it won't get done before the end of the hand edit on the master. ~|^ == --Toby. From the land down under: Australia. Do we look umop apisdn from up over? Do NOT CC me - I am subscribed to the list. Replies to the sender address will fail except from the list-server.
Backup MX server
Hello. Basic sendmail question. I want to set up a backup mx server to field incoming mail when my primary mail server goes down. I understand how to do this from a DNS standpoint, but what I don't know is what should be in my sendmail.mc/sendmail.cf file for this. Is there anything special I need to do for this? Anyone know any good documentation? Thanks. Chris
Re: Backup MX server
On Wed, Mar 01, 2006 at 07:19:18PM -0500, Chris wrote: Hello. Basic sendmail question. I want to set up a backup mx server to field incoming mail when my primary mail server goes down. I understand how to do this from a DNS standpoint, but what I don't know is what should be in my sendmail.mc/sendmail.cf file for this. Is there anything special I need to do for this? Anyone know any good documentation? Backup MX is a relic and a legacy. It breaks almost all spam filters. Modern mail infrastructure doesn't need it, except in rare cases. Save your other mailhost the trouble of dealing with all the double bounces and just skip it.
Re: Backup MX server
Really? So when the box goes down, just let the mail bounce? How would it break spamassassin (which is what I use)? David Terrell wrote: On Wed, Mar 01, 2006 at 07:19:18PM -0500, Chris wrote: Hello. Basic sendmail question. I want to set up a backup mx server to field incoming mail when my primary mail server goes down. I understand how to do this from a DNS standpoint, but what I don't know is what should be in my sendmail.mc/sendmail.cf file for this. Is there anything special I need to do for this? Anyone know any good documentation? Backup MX is a relic and a legacy. It breaks almost all spam filters. Modern mail infrastructure doesn't need it, except in rare cases. Save your other mailhost the trouble of dealing with all the double bounces and just skip it. -- This address is soon to be defunct. If you are anyone at all important to me, please contact me, and I will get you my new email address. Thanks, Chris
Re: Backup MX server
Backup MX is a relic and a legacy. It breaks almost all spam filters. Modern mail infrastructure doesn't need it, except in rare cases. why so? I use one here at work with great success. I use Postfix so I'm no use to the OP. I don't have any problems with double bounces, and my spam tools aren't broken. I have noticed that spammers won't even bother trying to connect to the primary, they just try the backup thinking that my primary server will accept mail as a relay from the backup, which of course it will, but only if that message passes spamd, 3 rbls, and amavis/SA, in which case it would have passed on the primary one anyway if I didn't have a backup configured at all. Seems to be just fine. --Bryan
Re: Backup MX server
On Wed, Mar 01, 2006, Chris wrote: I want to set up a backup mx server to field incoming mail when my primary mail server goes down. I understand how to do this from a DNS standpoint, but what I don't know is what should be in my sendmail.mc/sendmail.cf file for this. Is there anything special I need to do for this? Anyone know any good documentation? You need to allow relaying to the main server, see cf/README. PS: from the sendmail X README: Note about Backup MX Servers It is not a good idea to run a backup MX server B for a host A that has stronger anti-spam measures; if mails are sent to A via B, then B may accept them for delivery, but A may reject them and hence B has to sent bounces, which, in case of spam, are most likely to forged addresses, hence those bounces will only cause additional problems. The opposite case (B has stronger anti-spam measures than A) can cause the rejection of mail that A actually wanted to receive. Hence B and A should have the same anti-spam measures; i.e., a system that acts as backup MX server for another one should perform the same anti-spam checks as the main MX server(s).
Re: Backup MX server
On Wed, 1 Mar 2006 18:49:44 -0800, Claus Assmann wrote: On Wed, Mar 01, 2006, Chris wrote: I want to set up a backup mx server to field incoming mail when my primary mail server goes down. I understand how to do this from a DNS standpoint, but what I don't know is what should be in my sendmail.mc/sendmail.cf file for this. Is there anything special I need to do for this? Anyone know any good documentation? You need to allow relaying to the main server, see cf/README. PS: from the sendmail X README: Note about Backup MX Servers It is not a good idea to run a backup MX server B for a host A that has stronger anti-spam measures; if mails are sent to A via B, then B may accept them for delivery, but A may reject them and hence B has to sent bounces, which, in case of spam, are most likely to forged addresses, hence those bounces will only cause additional problems. The opposite case (B has stronger anti-spam measures than A) can cause the rejection of mail that A actually wanted to receive. Hence B and A should have the same anti-spam measures; i.e., a system that acts as backup MX server for another one should perform the same anti-spam checks as the main MX server(s). AND most importantly: BOTH servers MUST reject mail that is addressed to a non-existant recipient at the RCPT TO: phase. The very worst idea you can have about a secondary MX is that it doesn't need to know anything about the delivery domain other than the domain name itself. As a result spammers target secondaries strongly in preference to primaries. As a project I listed a secondary for a server I support using an alias on the same machine. All of the mail sent to the secondary address (unless I missed one or two) was spam. Only about 60% directed to the primary was spam. These days OpenBSD spamd does wonders and we don't use a secondary at all. Primary down = sender retries in a little while. Down means adsl out or power down longer than UPS reserve or hardware crash. I've not seen any of those last 24 hours and the common retry limit is in excess of 3 days. From the land down under: Australia. Do we look umop apisdn from up over? Do NOT CC me - I am subscribed to the list. Replies to the sender address will fail except from the list-server.
Re: Backup MX server
Backup MX is a relic and a legacy. It breaks almost all spam filters. Modern mail infrastructure doesn't need it, except in rare cases. me thinks this is spreading FUD. define modern mail infrastructure. perhaps the origin of the FUD is the M$ visual studio .net overexposure?
Re: Backup MX server
On Thursday 02 March 2006 10:47, [EMAIL PROTECTED] wrote: me thinks this is spreading FUD. define modern mail infrastructure. perhaps the origin of the FUD is the M$ visual studio .net overexposure? No, it's not FUD. The large majorityt domains dont need backup MX's. Mail wont bounce just because your primary/only MX is down, it will get queued at the sending MTA and delivered when your MX comes back up. --- Lars Hansson
Re: Backup MX server
Although I know where David is coming from with this slightly contentious comment, he's wrong. The argument is that most senders will do their own back-off, and the hassle of setting up a *good* backup MX server is so high that the benefit scarcely justifies it. However where he is wrong is not in the senders who don't resend (they're just broken anyway) or in the local clients who are sending outgoing mail via your server (bad idea anyway), but in clients who back off *for a long time* when they think you're down. In other words a backup MX lets you recover more quickly and more gracefully than not having one. Also critical is backup DNS. Let's assume we're looking at a disaster here, a long-term (5 day?) outage rather than a failed UPS. If your DNS is on the same net as the mailer, its down too. Senders soon get no result at all when they look you up, with the result that mail *bounces* (unknown address) rather than requeues. So set up a backup DNS even if you don't have a backup MX. Also for a major disaster, you probably don't want to continue secondarying your main (locally hosted) zone file. You may even want to replace the zone file on the backup MX host with a different one pointing to different servers, so you can have a web presence and maybe even some way of accessing your mail. In this case make sure you have a pre-prepared primary zone file that you can run on your backup DNS host, and have a protocol (i.e. a human protocol, phone no's and a password) so you can tell the remote person that it is time to switch from being a secondary DNS server to being a primary. You might even have your disaster site always running in preparation, just with no DNS normally pointing to it. (I do, and I'm not telling you the address ;-) ) In the event of a truly major disaster, with no telephones even, leave explicit instructions with this remote person on what circmstances they can kick in your backup DNS automatically, eg there is a national emergency reported on TV and your site has not been reachable for X days. Personally I do believe in Backup MX, as long as it does proper relay checking. It's nice if it also does spam checking, but not critical because your primary MX will still do that. However if you do spam checking *and rejection* on your backup MX, you'll significantly lower the load on the primary when it returns. Note that 5 days of pent-up mail arriving at once can kill a machine even if it is normally up to the peak loads you get, so you want a throttling control both on what the backup MX forwards to you when you return, and what you accept from other sources when you return. Graham
Re: Backup MX server
On Wed, Mar 01, 2006 at 11:16:59PM -0600, Graham Toal wrote: Personally I do believe in Backup MX, as long as it does proper relay checking. It's nice if it also does spam checking, but not critical because your primary MX will still do that. However if you do spam checking *and rejection* on your backup MX, you'll significantly lower the load on the primary when it returns. multiple prioritized MX is fine, as long as they're under the same administrative control with similar settings. Backup MX to me means some other site that just takes any mail for your domain and blindly forwards it on. I ran it for years. I've had other people run it for me. It's a disaster. In the modern world of spammers and smtp, any mail you have to generate a bounce message for (i.e. your relayhost accepts a mail for an invalid account on your primary host) means either someone else is getting junk from you or the backup host has to deal with double bounces. I prefer to avoid the junk.
Re: Backup MX server
On Wed, 01 Mar 2006 23:16:59 -0600, Graham Toal wrote: Although I know where David is coming from with this slightly contentious comment, he's wrong. The argument is that most senders will do their own back-off, and the hassle of setting up a *good* backup MX server is so high that the benefit scarcely justifies it. However where he is wrong is not in the senders who don't resend (they're just broken anyway) or in the local clients who are sending outgoing mail via your server (bad idea anyway), but in clients who back off *for a long time* when they think you're down. In other words a backup MX lets you recover more quickly and more gracefully than not having one. Also critical is backup DNS. Let's assume we're looking at a disaster here, a long-term (5 day?) outage rather than a failed UPS. If your DNS is on the same net as the mailer, its down too. Senders soon get no result at all when they look you up, with the result that mail *bounces* (unknown address) rather than requeues. NO - it does not! Well, not unless the sending MTA is broken. To quote from Postfix documentation referring to not getting an MX record from DNS: By default, the Postfix SMTP client defers delivery and tries again after some delay. This behavior is required by the SMTP standard. It also neglects the fact that lots of caching nameservers elsewhere will have a copy of the records that likely will not expire for quite sometime. I know mine are set to 3600 but I have had the sad experience of changing a domain from one dns hosting service to another and the old one had a TTL good for a week. So set up a backup DNS even if you don't have a backup MX. Also for a major disaster, you probably don't want to continue secondarying your main (locally hosted) zone file. You may even want to replace the zone file on the backup MX host with a different one pointing to different servers, so you can have a web presence and maybe even some way of accessing your mail. In this case make sure you have a pre-prepared primary zone file that you can run on your backup DNS host, and have a protocol (i.e. a human protocol, phone no's and a password) so you can tell the remote person that it is time to switch from being a secondary DNS server to being a primary. You might even have your disaster site always running in preparation, just with no DNS normally pointing to it. (I do, and I'm not telling you the address ;-) ) In the event of a truly major disaster, with no telephones even, leave explicit instructions with this remote person on what circmstances they can kick in your backup DNS automatically, eg there is a national emergency reported on TV and your site has not been reachable for X days. Personally I do believe in Backup MX, as long as it does proper relay checking. It's nice if it also does spam checking, but not critical because your primary MX will still do that. However if you do spam checking *and rejection* on your backup MX, you'll significantly lower the load on the primary when it returns. Note that 5 days of pent-up mail arriving at once can kill a machine even if it is normally up to the peak loads you get, so you want a throttling control both on what the backup MX forwards to you when you return, and what you accept from other sources when you return. 5 days of pent up mail will NOT all arrive at once. Not all of the senders will try again simultaneously and it is also likely that each of them will also not even flush all of the delayed messages in one batch. Rate limiting in decent MTAs mitigates the problem. That said, having backup DNS located elsewhere is never harmful as long as you can get it updated as fast as your master in house. Graham From the land down under: Australia. Do we look umop apisdn from up over? Do NOT CC me - I am subscribed to the list. Replies to the sender address will fail except from the list-server.
Re: Backup MX server
On Thursday, March 2, Rod.. Whitworth wrote: On Wed, 01 Mar 2006 23:16:59 -0600, Graham Toal wrote: If your DNS is on the same net as the mailer, its down too. Senders soon get no result at all when they look you up, with the result that mail *bounces* (unknown address) rather than requeues. NO - it does not! Well, not unless the sending MTA is broken. To quote from Postfix documentation referring to not getting an MX record from DNS: By default, the Postfix SMTP client defers delivery and tries again after some delay. This behavior is required by the SMTP standard. If the client can't find any DNS information on the destination, it tends to bounce. At least in all non-broken MTAs. Try it. Send email to [EMAIL PROTECTED] and see what happens. It also neglects the fact that lots of caching nameservers elsewhere will have a copy of the records that likely will not expire for quite sometime. I know mine are set to 3600 but I have had the sad experience of changing a domain from one dns hosting service to another and the old one had a TTL good for a week. This was 1/2 his argument. No DNS info means no DNS info. Not somewhere out there (sung like the song) we have a cache... Note that 5 days of pent-up mail arriving at once can kill a machine even if it is normally up to the peak loads you get, so you want a throttling control both on what the backup MX forwards to you when you return, and what you accept from other sources when you return. 5 days of pent up mail will NOT all arrive at once. Not all of the senders will try again simultaneously and it is also likely that each of them will also not even flush all of the delayed messages in one batch. Rate limiting in decent MTAs mitigates the problem. It most certainly will if the backup MTA sends it all at once. And if you read what you responded to, he said make sure that the backups to rate limiting. And you respond with Rate lmiting in decent MTAs mitigates the problem. So? Why are you saying what you are saying? That said, having backup DNS located elsewhere is never harmful as long as you can get it updated as fast as your master in house. scp, rsync, etc, etc. It will tend to get updated faster than the primary, considering you've got to edit the primiry's version by hand (usually). --Toby.
