This is where the following line is presented, replacing “” with your MTA’s name obviously, acting as the opening gambit of the transaction: 220 ESMTP PostfixĪs I’ve said, these delays might be because of DNS issues somewhere in the transaction chain and can obviously exist even when the server is running without excessive load, so don’t immediately jump to conclusions. You can fire up a Telnet session to your mail server (running the command telnet 25 ) and look for a slow initial response. On a basic level, you can probably spot a busy Postfix machine relatively easily. Or, of course, it could be due to an attack of varying flavors, and the deluge of email may not be legitimate or welcome at all. For example, a mail server that has been unavailable for some time (due to maintenance, network outages, DNS problems, or other issues) might suddenly become available again and empty its previously undelivered queue. There’s a whole host of reasons why a higher volume of usual of legitimate emails may arrive within a short period of time. Warning Signsįor Postfix, the point of no return is when the number of SMTP clients exceeds the number of SMTP server processes.
If there are unwieldy, sizeable attachments, you may see a slight performance hit because network IO and disk IO obviously need to stretch their legs, limber up, and get involved. It’s a very snappy retort with generally no latency visible to the human eye. When there’s no stress causing your mail server to creak at the seams, a standard response time is, for all intents and purposes, immediate. In this article, I’ll take a closer look at some warning signs and consider potential ways to mitigate issues when you spot that your server is stressed. As I discussed in the previous article, it’s clearly important to know when your trusty mail transfer agent (MTA) is struggling to perform its duties.
0 kommentar(er)
