3
SMTP Issues Since 7661 to 7669 Update
Problem reported by Jay Dubb - 1/4/2021 at 9:47 AM
Submitted
Immediately upon updating from 7661 to 7669, we started having delivery/SMTP issues.  Many internal devices (on the internal / private subnet) are not able to send system messages.  The SMTP connection opens (netstat shows port 25 open) but the message never comes in to the spool.  Secondly, we have a number of messages that came into spool... but just sit there.  No amount of restarting the SM service, "forcing" the messages, setting priority to high, or even rebooting the server itself, causes them to leave spool and deliver.  

Also, I've noticed Outlook takes an unusually long time (10+ seconds) to make an outbound SMTP connection to the server, regardless of which port (25, 465, 587).

Anyone seeing this, or might we have an isolated problem?

2 Replies

Reply to Thread
1
Andrea Rogers Replied
Employee Post
Hi Jay, 

We haven't heard any other reports of this issue. I'd recommend getting a support ticket submitted so our team can take a look at this. To submit a support ticket, log into the SmarterTools website. Then hover over the menu icon and select My Tickets. Click the New Ticket button to submit a ticket to the support department. 

Thank you,

Andrea Rogers
SmarterTools Inc.
877-357-6278

www.smartertools.com

1
Jay Dubb Replied
UPDATE:  The issue appears NOT to be DNS related after all, insofar as it relates to my original post (below).  We're back to ~15 seconds of delay on inbound SMTP sessions, even for whitelisted IPs.  According to the utility at MXtoolbox.com, the "SMTP Connection Time" is nearly instantaneous at 0.210 milliseconds, but the "SMTP Transaction Time" is over 15 seconds.  So the server answers the door immediately, but the transaction is very s.l.o.w.


Apologies for the noise, everyone.  The onset of the problem was purely coincidental to the update to 7669.  The root cause appears to be a DNS name resolution issue.  Specifically, we shut down a legacy DNS resolver, believing there were no remaining servers on the network still using it.  Except, one still did-- the mail server, which had it bound as the first DNS resolver.  Inbound SMTP connections trigger RBL checks, and those were slowed while queries to the first configured DNS resolver timed out, and then rolled to the 2nd resolver.  

Reply to Thread