Recently, after adding the mail tests I was surprised to see how many SMTP servers are taking longer then expected to send the welcome message, or to reply to a SMTP command. We wanted everything to be fast so we set time out of only 10 seconds for the connection and for every query sent. Soon I realized that 10 seconds was not enough…

The delays have almost nothing to do with the speed of our servers or the servers we test. A lot of delays are caused by how a SMTP server is configured.
Let’s take Exim for example which is used on all servers with cPanel.
This SMTP server by default does an ident request to the client or server that connects to it and only after an answer to that request is received or a timeout occurs (in most cases), the welcome message is sent. If you have cPanel on your server and have not modified the exim configuration manually, try a telnet to your SMTP host on port 25. You will most likely see a few seconds delay before the welcome message appears. This is happening in most cases because your SMTP server is doing that ident request. Do you have an ident server installed on your computer? No of course you don’t! Do your clients have one installed? No of course they don’t!

Identd is pointless and potentially dangerous and should not be used at all. You should consider changing your server settings not to use ident requests. In Exim you can do that by setting rfc1413_query_timeout to 0. After disabling the ident lookup, try telnetting again and see the difference.

Of course, ident is not the only problem that causes those delays. Another major problem in my opinion is that some servers verify the senders by connecting to the host that is sending the e-mail. This is not good at all, even if it seems to be very useful in preventing spam. Most of the spammers have very little understanding of what’s going on around them, but that doesn’t mean they will not adapt to changes.

Have you ever seen yahoo or Gmail connecting to one of your SMTP servers in order to verify the existence of an e-mail address? This will only lead to some mail being lost; it’s almost useless and will have an impact on your server’s performance. I recommend not using this type of verification at all.

I also agree that the Mail tests need to be improved along with other tests and we are doing our best.

This blog is about the IntoDNS journey. So let’s get started.

What?

IntoDNS checks the health and configuration of DNS servers and mail servers. It’s designed as a tool that helps server and network administrators in day to day job, to identify and fix DNS and mail issues.

Who?

IntoDNS is developed by a team of professionals from Elvsoft. Cristian Tomoiaga, an experienced system administrator, is the main project developer. Ovidiu Mocan and Adi Boiciuc worked on the graphic design and the clean XHTML & CSS code. Adi Andreias contributes to some of the tests and coordinates the whole project.

How?

We chose Python because it’s an elegant and powerful language with great multithreading support. And multithreading is crucial for IntoDNS’ performance. Django sets the web stage for Python and jQuery helps us with some of the tricks.

Where (are the ads)?

A strong project is a project that can sustain itself. But we don’t like web sites that have more ads then content. We don’t plan to overload intodns.com with screaming ads. When we’ll need a bunch of servers to sustain the traffic we ll probably come up with some sponsorship model with a single, small, nonintrusive and industry related ad. Drop us a line if you want to sustain IntoDNS.

Where to?

We plan to continue to improve IntoDNS and make it the best DNS health checker on the web. Feedback is very important to us. So don’t be shy.