Slow smtp with a 4 - 5 second delay

Question asked by Aftab Hussain - 8/6/2015 at 6:57 AM

Unanswered

I've virtualised a server with SmarterMail 12.5 running on it, the physical server had the following specification:

Dual Core CPU

4GB RAM

1GB NIC, connected to a 10/100 Switch

Sata Drives in RAID 1 Mirror

VM - Hyper-V

4 x CPU Cores, much faster Xeon CPU

4GB RAM

1GB physical NIC, 10GB Hyper-V Virtual Switch

SSD Drives in RAID 10

Latest Integration drivers installed.

The VM's is running with about 45% of ram being used and less then 10% cpu usage. The IP's on the server have been changed. So its not running out of resources. But I'm seeing a delay when mail is being accepted, one example:

13:40:30 [RemovedIP][63633256] rsp: 220
13:40:30 [RemovedIP][63633256] connected at 06/08/2015 13:40:30
13:40:30 [RemovedIP][63633256] cmd: EHLO
13:40:30 [RemovedIP][63633256] rsp: 250- Hello []250-SIZE 52428800250-AUTH LOGIN CRAM-MD5250-8BITMIME250 OK
13:40:30 [RemovedIP][63633256] cmd: AUTH login
13:40:30 [RemovedIP][63633256] Authenticating as
13:40:30 [RemovedIP][63633256] rsp: 334
13:40:30 [RemovedIP][63633256] rsp: 235 Authentication successful
13:40:30 [RemovedIP][63633256] Authenticated as
13:40:30 [RemovedIP][63633256] cmd: MAIL FROM:<>
13:40:30 [RemovedIP][63633256] rsp: 250 OK <> Sender ok
13:40:30 [RemovedIP][63633256] cmd: RCPT TO:<>
13:40:30 [RemovedIP][63633256] rsp: 250 OK <> Recipient ok
13:40:30 [RemovedIP][63633256] cmd: DATA
13:40:35 [RemovedIP][63633256] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
13:40:35 [RemovedIP][63633256] rsp: 250 OK
13:40:35 [RemovedIP][63633256] Data transfer succeeded, writing mail to 16092784.eml
13:40:35 [RemovedIP][63633256] cmd: MAIL FROM:<>
13:40:35 [RemovedIP][63633256] rsp: 250 OK <> Sender ok
13:40:35 [RemovedIP][63633256] cmd: RCPT TO:<>
13:40:35 [RemovedIP][63633256] rsp: 250 OK <> Recipient ok
13:40:35 [RemovedIP][63633256] cmd: DATA
13:40:39 [RemovedIP][63633256] rsp: 354 Start mail input; end with <CRLF>.<CRLF>
13:40:39 [RemovedIP][63633256] rsp: 250 OK
13:40:39 [RemovedIP][63633256] Data transfer succeeded, writing mail to 16092787.eml
13:41:31 [RemovedIP][63633256] disconnected at 06/08/2015 13:41:31

You can see after DATA there is a delay of 4 - 5 seconds, I also just noticed that ~50 seconds for the disconnect at the end, is that normal? I've cleaned up the log, to remove any identifiable information, so <> brackets weren't empty.

5 Replies

Reply to Thread

markus Replied

1/26/2016 at 12:33 PM

After trying to solve the same behavior for certain (!) connections on our server, I believe that the solution is: the connecting IP has no reverse DNS record (PTR)
Without this Smartermail seems to require 4-5 seconds after the DATA command until the PTR-lookup times out.

Aftab Hussain Replied

1/27/2016 at 3:19 AM

Thanks for this, I forgot to update, but this was the same thing we found.

Bruce Barnes Replied

1/27/2016 at 4:10 AM

Not having a reverse DNS for your IP will also get you blocked by lots of MX providers

Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting

markus Replied

1/27/2016 at 5:23 AM

of course! now they have created one.
In this case it was a customers webserver outsourced somewhere, and SMTP-Authenticating to Smartermail as his smarthost.
Under normal circumstances any SMTP-client connecting from the internet usually will have PTR-records from his eyeball-provider. And even if not he will not really note the 4-5 sec delay for each of his outgoing messages. For the webservers sendmail script this is a little bit different...

Bruce Barnes Replied

1/27/2016 at 7:54 AM

That's why all of our hosting contracts include the fact that we handle the customer's DNS servers for them.

Mail servers, IIS, and DNS have become so complicated that the simplest mistake can stop delivery and function completely. By having us handle all of the technical aspects of their hosting requirements, we're in a position to both:

monitor and control - before it becomes an emergency
troubleshoot without having to disrupt the customer's schedule
provide the latest stable releases of the products which the customer is running
do the required work without having to check with the customer on every detail
spend a lot less time resolving crises
monitor the expiration of their domain names and either renew them for them or remind them to do so

Without making an editorial comment on anyone's intelligence, and with all due respect for customers, both our current, and future, the reason the reason customers usually come to us is because they are either uncomfortable working with the detail required for the hosted services and/or DNS, or they have botched them up in the past and it cost them a lot of time or money. They are specialists in their fields of work and expertise, and we in ours.

Back to Community Threads

Please leave this box unchecked

5 Replies

Reply to Thread

Tags

Related Knowledge Base Articles