SMTP Send: NameResolutionFailure when using IP for smtp server

Hello,

I’ve a problem when sending email with the new library version (6.2.0.0). With the 5.3.0.0 version of Aspose.Email this code works fine:

Public Overridable Function SMTPSend(ByVal smtpServer As String, port As Integer, timeout As Integer, subject As String, sender As String, to As String,
body As String, ByVal userName As String, ByVal password As String) As Integer
Dim _smtp As SmtpClient = Nothing

Try
Dim mess As New MailMessage()
mess.From = sender
mess.To.Add(to.Trim)
mess.Subject = subject.Replace(vbCr, " ").Replace(vbLf, " ")
If body.Trim <> “” Then mess.HtmlBody = body
mess.Headers.Remove(“X-Unsent”)

Try
_smtp = New SmtpClient
If String.IsNullOrEmpty(userName) Then
With _smtp
.UseAuthentication = False
End With
Else
With _smtp
.Username = userName
.Password = password
.UseAuthentication = True
End With
End If
If timeout > 0 Then
_smtp.ConnectionTimeout = timeout * 1000
_smtp.Timeout = timeout * 1000
Else
_smtp.ConnectionTimeout = Integer.MaxValue
_smtp.Timeout = Integer.MaxValue
End If
_smtp.Host = smtpServer
_smtp.Port = port
_smtp.DeliveryMethod = SmtpDeliveryMethod.Network
_smtp.SecurityOptions = SecurityOptions.Auto
_smtp.AuthenticationMethod = SmtpAuthentication.Auto
_smtp.Send(mess)
Return 1
Catch ex As Exception
Me.txtLog.Text += ex.ToString + Environment.NewLine
Return -1
End Try
Return 0
Finally
If Not _smtp Is Nothing Then
_smtp.Dispose()
_smtp = Nothing
End If
End Try
End Function

With the 6.2.0.0 version of the library I obtain this error:

Failure sending mail. —> System.IO.IOException: NameResolutionFailure

I have also configured the SMTP client activity logging, but I cannot find any logs. I think the error occurs first and then the library can’t connect to the SMTP server.

I have this error only in some customer installation, when they use ip for the SMTP server (ad example 10.0.0.2) . In addition, SMTP is configured with anonymous authentication, and so username and password are always empty.

With the server name all works fine, however for some customers there are special network configurations and so we are obliged to use IP addresses. Can I change any parameter of the library and return to make things work like in the old version?

Thanks.

Hi,



Thank you for writing to Aspose Support team.



We have tested this issue at out end with the latest version of the API and were not able to reproduce the same problem. The API connects to the server without any error. Can you please confirm if the server IP is not behind a firewall? If possible, please share a test account details with us that we can use for investigating the issue further at our end.

Unfortunately, as for the other tickets, are servers of my clients and I can not share data.
The server is not behind a firewall. I tried to edit the hosts file of the local machine associating IP with a fictitious name. This way it works. There must be some problems using the IP in that configuration.
Since the older version (5.3.0.0) was working and new ones no, can I have a test version of the .DLL with some debug message to understand what the problem is? Something must have changed between the two versions.

Thanks.

Hi Alessandro,

Though it may require a little effort, but can you please test if any other version after 5.3.0 is working fine at your end? The list of changes can be found from our public API Changes section, but it seems difficult to find the exact reason in this case unless we have a test account that we can use to reproduce the problem at our end. We’ll discuss the issue with our Product team for further feedback in this regard and share with you as soon as some information is available. Please share the complete stack trace of the error as well for our analysis.

The last working version is the 5.5.0. From the 5.6.0 onwards there is the problem.

May it have been introduced some features that tries to resolve the name of the SMTP server, and give an error in the presence of a particular network configuration?

Thanks.

Hi Alessendro,

There have been alot of changes between the transition from 5.5.0 to 5.6.0 and these include major changes to the email communication clients. We are not sure what exactly may have given rise to this issue though. Can you please try the same with a public server such as Office 365 using its SMTP interface and share with us if you face any issue? We are unable to reproduce the problem at our end. We are afraid but without a sample test account, we may not be able to investigate this issue further at our end.

We just encountered this very same issue with one of our clients. Using a name instead of an IP address ended up resolving the issue, but the failure is still unfortunate as it should be possible to use an IP address. I subsequently found this point: https://forum.aspose.com/t/21031. This suggests to me that the problem may be the same for an SMTP connection as for IMAP and POP3. I observed with our client that they also did not have reverse DNS available for the IP address. This seems like a poor limitation of the library.

Hi Tim,

We have tested this issue with a public server (GMail in this case - you can get its SMTP IP by Ping it from command prompt using ping [smtp.gmail.com](http://smtp.gmail.com/)) and it didn’t raise any such exception. The email is sent out without any issue. Could you please arrange a test account on your server and share its credentials with us for testing the issue at our end? We’ll use it for reproducing the problem at our end and assist you further.

I’m sorry for the delayed reply - I missed the alert. I think you may be misunderstanding the issue. A public server such as GMail will have reverse DNS available for it (if you use nslookup on the IP address that you discovered, you will see that it yields a host name). If reverse DNS is available, the error does not occur. The error only occurs if reverse DNS is not available for the SMTP server, i.e., nslookup to the IP address does not yield a host name.


You should be able to configure an SMTP server on a machine and make sure that there is no reverse DNS entry for the machine on the DNS server to reproduce the problem.

Hi Tim,

Could you please share a test account information (IP + Credentials) on your server whose IP you are using to test this issue? Unfortunately, we don’t have any such facility to configure an SMTP server at our end for testing the problem. Or if it is possible, can you please help us in configuring SMTP server on our machine for testing the issue? We’ll look into it for further investigation and assist you accordingly.

Hi Tim,


The issue had been logged as EMAILNET-38403 in our issue tracking system for further investigation by our Product team. It is due for investigation in the next week on its turn as issues are dealt by first come first server basis. We’ll update you here as soon as there is some information available in this regard.

Kasif,


Just checking in to see the status of this issue.

Regards,
-Tim

Hi Tim,


We have investigated this issue at our end and found that the smtp ports were closed by then. The tests were made through some other opened ports and TCP connection was established correctly between SMTP client and remote server which shows that the problem was not with the reverse DNS. Unfortunately, the actually error message was ConnectFailure and internal error in this case which was misinterpreted as NameResolutionFailure error by our API. Please try it with the latest version of the API now and if you face any error, please provide us complete exception details of the error for our investigation. We’ll assist you further accordingly in this regard.

Can you please run your test again? The SMTP server is functioning again and the error still occurs.

Hi Tim,

Our Product team was able to connect earlier to your server using the information you provided and it doesn’t seem seem to be an issue with DNS. As requested, could you please share the complete exception details with us using the latest version of the API? Also, please provide us with the SMTP Activity Logging Information for helping us identify the issue at our end.

I see. It appears that the bug was resolved in the latest version of the API (6.7.0). We were previously using 6.2.0.

Hi Tim,


Please test it with the latest version of the API 6.7.0 and let us know if you face any issue.