4
Smarter Mail use 'A' record, if no MX record is found?
Question asked by Merle Wait - 9/4/2014 at 7:25 AM
Unanswered
So I have clients that are not pleased because this one client... can not receive email from our server. Root cause is that the domain has no MX record.  Thought that all domains have SOP of having MX.  Apparently not.
 
Where the client got upset is: Apparently sending through Yahoo & Google - both send to the offending domain.
The only thing that I can think of, is that they are using an 'A' record, when no MX record is found.
 
Apparently SmarterMail doesnt do that.... I am just curious whom else has ran into this.. and how you handled it?

21 Replies

Reply to Thread
2
Steve Reid Replied
You should contact the offending email server admin and tell them to fix their mistake.
 
There are already too many patches out there to fix peoples laziness... lol
0
Henry Timmes Replied
You should contact the offending email server admin and tell them to fix their mistake.
 
There are already too many patches out there to fix peoples laziness... lol
If he's right this is a big bug in smartermail - According to RFC standards if no MX records are found then emails should be sent to the A record. I think I wouldn't of encountered this by now, if this was the case, should be easily enough to test. But Smartermail should know off the top of their head if they don't check for A records. 
 
Campaign Cleaner - The Ultimate Tool for Optimized, High-Performance Email Campaigns
0
Steve Reid Replied
That is a pretty crazy RFC standard then...
2
Henry Timmes Replied
RFC 5321 sec. 5 now clearly states that:
 
1) SMTP clients must look up for an MX record;
2) if no MX record for domain is present, look up for an A Resource Record (RR), and if such record is present, treat it as an MX record;
3) if an MX record is present, clients MUST NOT use an A RR.
 
  5.1 Locating the Target Host
  Once an SMTP client lexically identifies a domain to which mail will
  be delivered for processing (as described in Sections 2.3.5 and 3.6),
  a DNS lookup MUST be performed to resolve the domain name (RFC 1035
  [2]). The names are expected to be fully qualified domain names
  (FQDNs): mechanisms for inferring FQDNs from partial names or local
  aliases are outside of this specification. Due to a history of
  problems, SMTP servers used for initial submission of messages SHOULD
  NOT make such inferences (Message Submission Servers [18] have
  somewhat more flexibility) and intermediate (relay) SMTP servers MUST
  NOT make them.
  
  The lookup first attempts to locate an MX record associated with the
  name.  If a CNAME record is found, the resulting name is processed as
  if it were the initial name.  If a non-existent domain error is
  returned, this situation MUST be reported as an error.  If a
  temporary error is returned, the message MUST be queued and retried
  later (see Section 4.5.4.1).  If an empty list of MXs is returned,
  the address is treated as if it was associated with an implicit MX
  RR, with a preference of 0, pointing to that host
Campaign Cleaner - The Ultimate Tool for Optimized, High-Performance Email Campaigns
0
Merle Wait Replied
Received an email back from SmarterMail tech... saying that SmarterMail  indeed  checks for A records.... But if that is the case... why am getting that error?    This was all started because I had a user complain...  and I didn't realize that the clicking "view recipient on the email in queue would show "  So I opened a ticket (and yes I got most excellent response).
 
601 Failed to connect to the recipients mail server. No MX records were found for the 'XXXXXX.com' domain. Attempted to send the message to the following ip's: 69.43.XXX.XXX 
So I thought end of story.....  Still thought maybe end-of-story... and that 'A' record was wrong.... but confirmed via sending email from Yahoo & Google... they send it on through... 
So puzzeling... maybe more to come.
0
Steve Reid Replied
Try checking the domain at intodns.com
0
Merle Wait Replied
Thanks for the info... I did do that.. .all the boxes were green except for the MX record.... ( I have been using http://network-tools.com/ previously)
0
Bruce Barnes Replied
if you post the domain name we can do some additional checking, too.
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
0
Merle Wait Replied
paccer.com
0
Steve Reid Replied
I tried to telnet into their www a record but it doesn't work. If this A record is not the email server then how the heck is smartermail supposed to magically know their email server location?
0
Merle Wait Replied
I don't know... I just tried a different brand of email server that we have (actually two different brands)....
Neither worked...  So I don't know how Yahoo & Google do it...  but... a for me & my email servers... without proper info... I give up.    So not sure where to go from here, certainly not a SmarterMail issue that I can tell.
0
Steve Reid Replied
I still say you should contact them an ask them to add an MX record. It's literally 5 mins work.
4
Bruce Barnes Replied
Testing for PACCEER.COM - shows multiple issues, including DNS records and MX records, IE:
 
DNS appears to have both DNS servers sharing the same IP addresses.  While it may be legal, it can cause lookup issues:
 
 
 
 
 
 
 
Testing from: DNSSTUFF.COM using the MX SERVER TEST CENTER (requires FREE subscription):
 
 
 
 
 
 
 
 
 
 
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
0
Grant Boshoff Replied
It's obviously a bug according to RFC 5321 sec. 5 as noted by Henry Timmes earlier in the thread, but paying for a support ticket for me to report the bug seems...wrong. Has anyone heard any news on this bug?
0
Employee Replied
Employee Post
Hi Grant! SmarterMail does actually check for, and send to, the A record if an MX record is not present. If you're having trouble with this and the issue IS caused by a bug in the software, your ticket will be refunded. However, typically for issues like these, a support ticket is necessary to give our support team a chance to look into the issue and determine what the cause is.
1
Bruce Barnes Replied
Per the fact that port 25 was down, when tested, it's not a bug with SmarterMail, but a problem on the recipient’s end.
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
1
CCC Replied
For what its worth, I have recently diagnosed two separate instances where a customer was reporting bounced emails, and it turned out to be related to the A record fail over. 
 
Having not seen this issue in a long time - I was suspect at first, however in both cases there were intermittent DNS errors on the remote end which likely instigated the A record fail over.
 
I would like to suggest that SmarterMail add a "one liner" to the detailed delivery logs that says something like
MX lookup for domain.com failed from dns.server.name - failing over to A record
That would make it very easy for SmarterMail users (and support) to prove that the A record failover happened due to external DNS issues.
 
0
Matt Petty Replied
Employee Post
Done!
You will now see
"Failed to connect to the recipients mail server. No MX records were found for the '<domain>' domain. Failing over to A records."
Means you should see this is future builds of 15 (and 16).
Matt Petty Senior Software Developer SmarterTools Inc. www.smartertools.com
0
CCC Replied
Great! This should make troubleshooting much easier for both of us. Thanks!
1
Richard Frank Replied
how gladly I would like to see that if there are no mx records the mail just gets dropped. there are a lot of mails like this waiting in the spool to be delivered to an IP number that is found.
 
I would suggest, that if MX records aren't found and connection on port 25 on A records fail that the mail will bounce immediatly.Now those mails sit in the spool waiting until the retry timer times out.
*wishfull thinking*
1
CCC Replied

Version 15.5.6222 (Jan 13, 2017)

  • Added: A log entry is made whenever a delivery attempts an A record lookup.
 
This feature just saved me a bunch of troubleshooting time this morning. Thank you!!!!! 

Reply to Thread