Mailing List Message #105815
From: James Roman <>
Subject: Re: Unique entries for SMTP Prompt Delay
Date: Mon, 14 Sep 2015 09:02:01 -0400
To: CommuniGate Pro Discussions <>
X-Mailer: Apple Mail (2.2104)
We’ve been playing with this as well. We’ve noticed two benefits to extending the initial prompt delay with an isolated domain:

• The longer (> 10s and then >30s) delays accounts for a 10% drop in incoming message volume (SMTP messages accepted) each. Nearly all messages removed are spam messages. Less than 1% of messages removed are in fact valid email senders. While the overall volume drops, the percentage of the total messages caught by our local content filtering (spam and virus) also fall, by roughly 10% split between the two. 
• Giving spam/virus filters a few extra seconds before they start checking blacklists provides a significant improvement in accuracy. (There are fewer false negatives, or “Missed spam” messages delivered to Inboxes.)

However, the downside, as mentioned is that numerous valid sending mail systems no longer wait an extended period for a prompt. I believe the RFC states that the sender should wait up to 5 minutes for an SMTP response, most likely stemming for the days when mail servers could be sitting behind a dial up connection. Obviously the companies that don’t wait have only dealt with land-based, terrestrial email communication. 

We found that our biggest issues came from various cloud-based email service providers and especially filtering providers. I’m guessing that they are trying to reduce their cloud storage requirements, but cynicism would also suggest that as they gain more customers, there is less incentive to allow such simple improvement in local filtering performance as it comes at the expense of their relative effectiveness. This is one way we noticed for cloud-based spam providers to inflate their effectiveness numbers. Others include sharing SMTP gateways, so messages rejected for all domains on that gateway at the SMTP HELO or MAIL FROM: get counted in all message totals, because prior to the SMTP RCPT TO: no one can know which domain the message is intended. With one cloud filtering provider we noticed a 4-fold increase in message volume attributed to our domain during testing due to these practices.

From our observations, it was always better to set the timer 1 second short of a ten second interval (9s, 19s, 29,s) than a multiple of 10.

Long and short of this is that you may be able to consider longer prompt delays (> 2s) if you host a single domain. If you host multiple domains, or use multiple gateways, the costs will most likely far outweigh the benefits. 

On Sep 11, 2015, at 7:00 AM, CommuniGate Pro Discussions <> wrote:

From: "Bill Cole" <>
Subject: Re: Unique entries for SMTP Prompt Delay
Date: September 10, 2015 at 10:43:38 PM EDT

On 10 Sep 2015, at 14:39, Tom Rymes wrote:

Today, however, I accidentally discovered that my currently configured prompt delay for SMTP (currently set to 23s) was to blame. While testing, I set the delay to 2s and suddenly a slew of e-mails showed up in my inbox.

Based on over a decade of using greeting delays with Sendmail, Postfix, and other tools that allow for measurement of just how fast offenders talk and how long impatient senders will wait, I'd say 2s is very close to the sweet spot for a greeting pause. The last time I did a careful analysis with varying times was years ago, but I've never seen in production or testing any negative impact of delays <5s and the vast majority of fast-talkers start in under a half-second because they are predominantly hyper-optimized sending bots. The legitimate(ish) senders who fast-talked before delays were common have all reformed their practices and the most impatient senders who once timed out too fast have mostly been spanked into compliance with the standard or at least something within an order of magnitude. It's a bit of a surprise that any sender worth caring about is still giving up in <23s, but I guess stupidity has a very long tail.

Subscribe (FEED) Subscribe (DIGEST) Subscribe (INDEX) Unsubscribe Mail to Listmaster