Smarter Mail use 'A' record, if no MX record is found?
Question asked by Merle Wait - September 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?

11 Replies

Reply to Thread
2
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
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. 
 
www.unlocktheinbox.com
2
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
www.unlocktheinbox.com
0
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
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.
4
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
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?
1
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
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.
 
1
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

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