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
'If you want to BCC this email to someone else...
If bcc.Length <> 0 Then
objMM.Bcc = bcc
'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"