Emails bypassing MX priorities?
in [Sendmail]
|
Prev: Second NIC, Failover ISP, one Sendmail server, how will it work
Next: bare minimum sendmail config for full masquerading
From: CGI-Carl on 11 Apr 2008 15:25 Hi, We recently ran into a problem in our email alert system. We are currently using Sendmail as a relay to deliver to outsides domains and ,while it does it reliably, the emails sent to one particular domain sometimes time out during the delivery and they show up 30 minutes later, something that we cant afford. Here's the result of my nslookup to see the MX servers related to the recipient's domain: [root(a)sendmail /]# nslookup > set type=MX > pager.bellmobility.ca Server: 192.168.248.5 Address: 192.168.248.5#53 Non-authoritative answer: pager.bellmobility.ca mail exchanger = 5 bm.srvr.bell.ca. pager.bellmobility.ca mail exchanger = 10 mail.txt.bell.ca. Authoritative answers can be found from: bellmobility.ca nameserver = ns1.mobility.com. bellmobility.ca nameserver = ns1.bellglobal.com. bellmobility.ca nameserver = ns2.mobility.com. bm.srvr.bell.ca internet address = 206.47.199.69 bm.srvr.bell.ca internet address = 209.226.175.252 mail.txt.bell.ca internet address = 206.47.78.138 ns1.bellglobal.com internet address = 198.235.216.1 Now here's the part of maillog related to a specific mail who came in 30 minutes too late. Apr 10 04:47:47 sendmailserver01 sendmail[29898]: m3A8jlrv029893: to=<XXXXXXX(a)pager.bellmobility.ca>, delay=00:02:00, xdelay=00:02:00, mailer=esmtp, pri=120881, relay=mail.txt.bell.ca. [206.47.78.138], dsn=4.0.0, stat=Deferred: Connection timed out with mail.txt.bell.ca. Apr 10 05:21:53 sendmailserver01 sendmail[30730]: m3A8jlrv029893: to=<XXXXXXX(a)pager.bellmobility.ca>, delay=00:36:06, xdelay=00:00:16, mailer=esmtp, pri=210881, relay=bm.srvr.bell.ca. [206.47.199.69], dsn=2.0.0, stat=Sent (ok: Message 197821071 accepted) What could cause Sendmail to fallback on the higher cost MX without even trying the primary? We are not using any domain routing, mailertable is clear, our Sendmail version is Sendmail 8.13.1/8.13.1 running on a CentOS release 4.4. I did a fair bit of reseach and came out empty-handed so any lead would be apreciated.
From: Bill Cole on 13 Apr 2008 23:23 In article <86f928d1-b9c5-43f7-be0e-2d2821901a44(a)t54g2000hsg.googlegroups.com>, CGI-Carl <carl.r.tremblay(a)cgi.com> wrote: > Hi, > > We recently ran into a problem in our email alert system. We are > currently using Sendmail as a relay to deliver to outsides domains > and ,while it does it reliably, the emails sent to one particular > domain sometimes time out during the delivery and they show up 30 > minutes later, something that we cant afford. Then you are mistaken about the nature of email and its applicability to the task you have given it. Perhaps you would be better off with a direct pager or SMS gateway of your own rather than Internet email. > Here's the result of my nslookup to see the MX servers related to the > recipient's domain: > > [root(a)sendmail /]# nslookup > > set type=MX > > pager.bellmobility.ca > Server: 192.168.248.5 > Address: 192.168.248.5#53 > > Non-authoritative answer: > pager.bellmobility.ca mail exchanger = 5 bm.srvr.bell.ca. > pager.bellmobility.ca mail exchanger = 10 mail.txt.bell.ca. > > Authoritative answers can be found from: > bellmobility.ca nameserver = ns1.mobility.com. > bellmobility.ca nameserver = ns1.bellglobal.com. > bellmobility.ca nameserver = ns2.mobility.com. > bm.srvr.bell.ca internet address = 206.47.199.69 > bm.srvr.bell.ca internet address = 209.226.175.252 > mail.txt.bell.ca internet address = 206.47.78.138 > ns1.bellglobal.com internet address = 198.235.216.1 > > > Now here's the part of maillog related to a specific mail who came in > 30 minutes too late. > > Apr 10 04:47:47 sendmailserver01 sendmail[29898]: m3A8jlrv029893: > to=<XXXXXXX(a)pager.bellmobility.ca>, delay=00:02:00, xdelay=00:02:00, > mailer=esmtp, pri=120881, relay=mail.txt.bell.ca. [206.47.78.138], > dsn=4.0.0, stat=Deferred: Connection timed out with mail.txt.bell.ca. > Apr 10 05:21:53 sendmailserver01 sendmail[30730]: m3A8jlrv029893: > to=<XXXXXXX(a)pager.bellmobility.ca>, delay=00:36:06, xdelay=00:00:16, > mailer=esmtp, pri=210881, relay=bm.srvr.bell.ca. [206.47.199.69], > dsn=2.0.0, stat=Sent (ok: Message 197821071 accepted) > > > What could cause Sendmail to fallback on the higher cost MX without > even trying the primary? A cached host status could do that. If you are using host status caching, you probably want to switch it off if immediacy is important to you. > We are not using any domain routing, > mailertable is clear, our Sendmail version is Sendmail 8.13.1/8.13.1 > running on a CentOS release 4.4. I did a fair bit of reseach and came > out empty-handed so any lead would be apreciated. -- Now where did I hide that website...
From: Grant Taylor on 14 Apr 2008 15:14 On 04/13/08 22:23, Bill Cole wrote: > A cached host status could do that. If you are using host status > caching, you probably want to switch it off if immediacy is important > to you. I would also suggest that you look in to using the DELIVER BY option so you will get a notice elsewhere if there is a problem delivering the message(s) with in the time specified. Grant. . . .
From: CGI-Carl on 14 Apr 2008 16:35 On 04/13/08 22:23, Bill Cole wrote: > > > A cached host status could do that. If you are using host status > > caching, you probably want to switch it off if immediacy is important > > to you. Wouldnt that cause every email directed to that domain to bounce back if it was due to cache? We dont use nscd on our sendmail server. Tracking the problem is hard since I cant reproduce the error manually because it is a random event, maybe 1 in 30 emails goes directly to the secondary MX server. As for the fact that we're using emails as a warning method, unfortunately, I have to work with it for now. The question: What other option or config could cause mail to bypass the priorities of MX servers and head for the secondary randomly? If the sendmail server was contacting the primary everytime, we wouldnt be in this mess. >I would also suggest that you look in to using the DELIVER BY option so >you will get a notice elsewhere if there is a problem delivering the >message(s) with in the time specified. Could you please elaborate?
From: Grant Taylor on 14 Apr 2008 18:06
On 04/14/08 15:35, CGI-Carl wrote: > Could you please elaborate? http://www.rfc-editor.org/rfc/rfc2852.txt If memory serves, DELIVERBY is an option supported by some servers (Sendmail and others) that instructs the system to either deliver the message (as it normally would) with in the time specified or to return an error (DSN) to the (envelope) sender of the message indicating that the message was not able to be delivered in time. So what I was referring to was that you could send your messages from a known email address using the DELIVERBY option so that the said email address would receive notifications if the emails were not able to be sent with in the time specified. This would at least let you know that the message did not make it to your intended recipient(s). Hopefully this knowledge would help you. Grant. . . . |