In any complicated database environment, SMTP communication acts as a lifeline from the monitoring aspect. This not only means a pivotal mail subsystem communicating the right alert at the right point in time but also being consistent without abrupt network packet drops.

In other words, a situation arises when critical alerts stop getting delivered to the DBA team because of an issue either with the SMTP reachability or a network issue otherwise. In such a scenario where we have seen it happening for MS SQL Server, the respective team quickly needs to be engaged to avoid any large impact.

A quick isolation procedure involves understanding the workflow associated with SMTP communication, both on a secure channel & otherwise. As evident, the method is complex and most likely an organization like us with adequate exposure to handling of large databases understand the critical dependency for it. So, the first check needs to be done at the port level 587 (Secure communication) or 25 (open relay, usually defunct nowadays).

Thus, once Telnet can reach the SMTP server on one of the ports as stated above, then SMTP reachability can be concluded to be active and largely stable.

As a matter of fact, to conclude though the point remains that a trained team understands the value of a quick isolation and forms the heart of a complex database support system. Thus, the importance of SMTP issue isolation is high and undeniably the assurance from Scalability thus runs high enough to be of respect & value.