If port 25 is blocked as evidenced by telnet attempt, how is this ASP.NET application sending mail and over what port?

I will be doing an Email-Only migration. It has now been postponed because the application developer cannot test the apps and ensure that they are "SMTP-relayed" to the IronPorts in the new domain.

His apps are and have been able to send email from three apps servers to their local Exchange server, using the following line in his ASP.NET 2.0 code: SmtpMail.SmtpServer = "smtp.current.domain.name". One thing I am confused about is that smtp as seen in code above, is NOT the name of their Exchange server.

All persons involved in discussion have thought that it must be communicating over port 25, but I looked at settings on McAfee on apps servers and there is a setting to explicitly block port 25, with exceptions including programs such as Outlook.exe and nsmtp.exe. I have not asked yet, but I do not believe a new Outlook message pops up as a result. So this is something else that confuses me: if email IS being routed from the apps servers to the local Exchange server using this line of code, and port 25 is blocked then what port IS being used? I tried to telnet from the apps servers to the local Exchange server on port 25 and cannot open a connection. However, on the Exchange server, the SMTP connector is already configured to point to the IronPort FQDN on target domain. Hmmm.. COULD IT BE THAT the applications servers mail is also being routed directly through this SMTP connector, which IS in turn relaying directly to the desired IronPort location in new domain? Maybe it is not going from the apps servers to local Exchange server via port 25; even though it is of course going over port 25 once it hits the SMTP connector.

If this application interface is a web page, is there a change that the mail is being sent over port 80 to the Exchange server? Or if it is simply a form, and not using a browser, could it possibly communicate by resolving the FQDN and "sending" via DNS to Exchange server?

I need to allow the apps developer to relay SMTP traffic to the new domain, because we are only migrating email at this point. Their Exchange server will be decommissioned. There is no domain trust. The Domain and Directory Migration will commence after they move to a new building. We could leave the Exchange server up until subsequent migration, but the apps developer wants to feel good about his applications continuing to communicate in the new environment.

So my question, I suppose, is what reason, if any, should I have to believe that if I change the FQDN of the new smtp server in this code: SmtpMail.SmtpServer = "smtp.new.domain.name", email will not continue to be routed, assuming that the new smtp server does not require authentication, and, as in our situation, the IP addresses of the source apps servers have been added to the ACLs on the IronPort in new domain.

I believe that if he were to put in the FQDN of the new Exchange server or "smtp.new.domain.name", then mail WOULD continue to be routed. Actually, I will be putting in the FQDN of the IronPorts, which is already the setting that exists in the SMTP connector on their Exchange server. He can create a copy of an application and test this, but has insisted that we get it right first. Also, firewalls have been ruled out as a factor on source and target.

Please let me know if more information is needed. Thank you. Brian
Public Sub sendMail(ByVal from As String, ByVal too As String, ByVal cc As String, ByVal bcc As String, ByVal subject As String, ByVal body As String)
        Dim objMM As New MailMessage
        'Set the properties
        objMM.To = too
        objMM.From = from
        'If you want to CC this email to someone else...
        If cc.Length <> 0 Then
            objMM.Cc = cc
        End If
        'If you want to BCC this email to someone else...
        If bcc.Length <> 0 Then
            objMM.Bcc = bcc
        End If
        'Send the email in text format
        objMM.BodyFormat = MailFormat.Text
        '(to send HTML format, change MailFormat.Text to MailFormat.Html)
        'Set the priority - options are High, Low, and Normal
        objMM.Priority = MailPriority.Normal
        'Set the subject
        objMM.Subject = subject
        'Set the body - use VbCrLf to insert a carriage return
        objMM.Body = body
        SmtpMail.SmtpServer = "smtp.current.domain.name"
    End Sub

Open in new window

Who is Participating?
debuggerauConnect With a Mentor Commented:
that just a subroutine, other routines may be the actual sending routine..
Because that generic name would never get resolved unless your domain was named domain (or at least has a DNS entry for it).

As far as port 25, it may be using ssl, which would make the port commonly 465, but could be set to a custom port (and the standard smtp port may have been changed too, especially if it is a closed network).

If you really wanted to check his app, I'd suggest using wireshark (or I like smsniff) to sniff the wire while the app is working. You'll get all the port info you need...
Steven WellsConnect With a Mentor Systems AdministratorCommented:

this sub routine is actually sending the email.

The part that sends the email is


if this is from an asp.net site, there could be other settings , including server settings, in the web.config file in the root of the webapplication.

This does use port 25 unless specified.

I have used this code in my asp.net applications and have no problems.
There could be another smtp server in your network that is actually doing the relay. STMP services can be installed on any server.

You should only need to change the smtp host name (or IP address) and it should all be working. You may also need to change any "From" addresses.
In this situation, I would relay off the internal mail server, not any external anti-spam. You can specifiy usernames in asp.net so that helps with security.

kontrariankidAuthor Commented:
Thank you both for your great advice!

The generic name I included here was on purpose just for practical reasons. We actually used the IP address and it worked just fine for the two internal servers. As for the server in the DMZ, there were outbound rules added in the PIX, and we determined that additional rules, such as the one below, needed to be added to the firewall to specifically allow communication to those IronPort IPs. Once we got someone to get access and add them, then the applications on the DMZ server were also successfully going out to the internet and talking to the IronPorts in the new domain.

access-list acl_dmz1 permit tcp host host xxx.xx.xx.183 eq smtp
kontrariankidAuthor Commented:
We still cannot telnet at port 25, but nevertheless the apps are talking, so still curious as to what is actually being done when this button is clicked and the email is sent. Anyhow, everything is working fine. I will be downloading a "sniffer". A colleague downloaded TCPView. Thank you.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.