Hello John,

I'd be happy to escalate this as a feature request. Can you tell me a preferable alternative to failing over to A records when MX records are unavailable? Currently this is an intended feature and not considered a problem.

Best,

If there is no MX record, bounce. End of story. In all honesty, it is that simple. There is no RFC stipulating in any case or way that when there is no MX record that other attempts to delivery should be made.

Hi John,

  Here is the RFC stating they must try the A record :

"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."

  I would interpret "pointing to that host" being the A record of the portion after the @

Kind Regards,

-dave

While in theory and trying ONCE is acceptable, if attempting to connect to an A record also fails, the email must be considered undeliverable and bounced immediately. 

With the way it works now, and with the need to have the retry period for delivery attempts, as in this case, there is absolutely no email associated with that domain yet SmarterMail just keeps ignoring that fact and requeues it for later retry, per the configured retry interval which is designed for 48 hours.

But if there is no MX record and an A record does not respond, that must be treated immediately as undeliverable. 

In this case, the sender made a mistake in the email address but because of the retry period will not get a NDR until 48 hours later, instead of within say 30 minutes.

+1.  Either "once to the A record then bounce" or "bounce on no MX".  

It used to be more common for lazy webhosts to set up a shared hosting account with just the A record, and do the whole show (web, ftp, dns, email) on the same box.  That was then, this is now.  Surely there are still some who do, but that was a lot more common in the 90s and early 2000s.  Can't remember the last time I saw a host putting email and www on the same box, at the same IP.

 

Hi Everyone,

About a year ago, we decided to remove the behavior in SmarterMail that allowed failing over to A records when MX records were unavailable. Unfortunately, this change led to significant issues when contacting our customers—around 10% to 20% of email domains we encountered only had A records and no MX records. Due to this, we reverted to the original behavior. We also confirmed that other major email providers, like Gmail, handle this similarly.

To mitigate potential issues, I recommend adjusting your settings as follows:

This ensures that if an email is undeliverable, the sender will be notified quickly and can take action to correct the issue. I hope this helps.

Best regards,

Zack, in the case I had on 08/22, there is no evidence any delay email was generated and sent.

I have that setting set to 4, which is a cumulative of 1 hour.

Hey John, 

In that case, this would be a bug. I would recommend reaching out to support to see if they can replicate this so we can get it fixed. 

Kind Regards, 

Aside from the bug that is now being addressed about the delay emails, SmarterMail needs to change the behavior of the use of A records.

In the settings is "DNS Errors Before Bounce" and my setting is 2.

This should also apply to the lack of an MX record. If there is no MX record, and SmarterMail insists on attempting to use an A record, then that should ONLY BE ATTEMPTED the amount of times that is set in the "DNS Errors Before Bounce" since that is indeed a DNS error.

SmarterMail must not continue to try to connect to an A record when there is no response or a timeout.

No.   Non-delivery processing is the same, whether the destination is an MX or an A name.   This is per the RFC.

One of the limitations of SmarterMail is that you have poor visibility to the message logs, both incoming and outgoing.   That problem can be solved by building your own web solution or by buying a commercial product with a good message review interface, including both delivered and pending messages.   

We use a Barracuda appliance as a component of our incoming gateway sequence,  It is also the only outbound gateway.   It does a decent job of content filtering.   For what I wanted, Barracuda is very weak on sender filtering, so we built a front-end gateway using SmarterMail Free, Declude, Python, and SQL   

Barracuda has a specific web page for messages that are stuck and awaiting retry.   Once you see a stuck message, you can bounce the message and notify the user about their spelling error.   

Barracuda also provides a secure web relay solution for sensitive outbound messages.    We want all outbound messages to go encrypted, so we set Barracuda to require outbound encryption, then catch the problems and force those destination domains through the secure web relay.

I'm not sure how much life remain in the appliance gateway market, because Barracuda is moving to the cloud like everyone else.   Their appliance is capacity-priced, which works very well for us.  Their cloud solution is price per-user, which works out to a lot more money for us.   I think the appliance pricing will be within the budget of email hosting services on this forum, but I only see the annual maintenance fees, since I have not bought one for cash in more than 15 years.   (We use their option for system maintenance includes a new box every 4 years, to avoid obsolescence or repurchase.)

One thing that SmarterMail could do is:

- Attempt delivery to the A record.

- On failures, ping the A address to see if it is up.

- If ping fails, assume that the box is down and follow the normal requeue process.

- If the ping succeeds, assume that the box is up but it does not have port 25 open.   Shorten the retry process.

Since the last step is not RFC compliant, using that option should be a configuration option given to the system administrator.