I have a webserver that was setup using CentOS and we have contact forms on it that send email and everything worked great on the internal network. We was told to make the website live and we changed the IP address of the server and moved it into the DMZ now it will not send email. If I move it back into our internal trusted network it works fine. The network path is allowed as I can send email with a windows server also in the DMZ using a vbscript file just as a test. Is there something else I need to change after moving this into the DMZ?

if i look in the maillog i see this...
Nov 1 15:37:44 localhost sendmail[1644]: wA1JbYES001642: to=<somename@mydomain.com>, delay=00:00:10, xdelay=00:00:09, mailer=esmtp, pri=120512, relay=mail2.mydomain.com. [1.2.3.4], dsn=4.0.0, stat=Deferred: Connection reset by mail2.mydomain.com.

I changed the real IP address to 1.2.3.4 and host names to mydomain.com.

Any ideas?

I should also add that I did a packet capture on the interface this connects to and there are no packets even going out to the email server.

Have you tried sending email from command line to see if that works?
echo "test email" | mail -s "test email from command line" -r donotreply@yahoo.com <your valid email address here>

Also, send a test email with telneting to SMTP server; steps are here:
https://linuxconfig.org/send-an-email-using-telnet

If that works, then check your settings in web application that sends emails

Some clarifications, please.
You said the server "will not send email", but the log entry you posted shows that it tried to send the email and that the connection to mail2.mydomain.com was reset.
Is mail2.mydomain.com your server? If so, it's apparently not configured to allow relaying from the new IP address.

when trying telnet it says "connection closed by foreign host"

some more information. Maybe this will clarify.

The exchange server is in our internal (trusted network) 192.168.0.0/24 (subnet allowed to relay 192.168.100.0/24)

(telnet connects to exchange from here) CentOS server in the internal (trusted network) 192.168.0.0/24

(telnet connects to exchange from here) Windows server in the DMZ (optional network) 192.168.100.0/24

(telnet does NOT connect to exchange from here) CentOS server in the DMZ (optional network) 192.168.100.0/24

You said the problem occurred when you made the server "public" A public server wouldn't have an IP in the 192.168.x.x netblock, right?

Is the IP you masked in your OP the IP of the mail (exchange) server or the sending server? It still looks to me like the sending server is not authorized/trusted when it's in the DMZ, which, presumably, you'd have to configure on the exchange server.

When I say public I mean move it into the DMZ which all of the servers in my DMZ do have a 192.168.100.0/24 address. There is a firewall in front of that where the public ip address is and the port is forward to the server.

the masked IP in the original post is the mail server public ip address.


I added the entire subnet of the DMZ to the exchange allow to relay list so if the windows server can connect and send mail the others should too right?

Also if I understand the telnet output right... it's not really a question of attempting to relay.

it looks like it connects and then just drops it. i should be able to authenticate and send mail or attempt to relay mail and it should say unable to relay. Or maybe I don't understand whats happening here.

(yes the IP is masked)

[user@host ~]$ telnet 1.2.3.4 25
Trying 1.2.3.4...
Connected to 1.2.3.4.
Escape character is '^]'.
Connection closed by foreign host.

Hmmm. Still going to say that's an issue with the exchange server configuration. I don't speak MS email, tho. Sorry.

This is not correct; you need to make sure that firewall between server in DMZ and your SMTP server on internal network allows SMTP (TCP Port 25).

Here is what you should see:

Here I am using "donotreply@yahoo.com" as sender address, which I know works...

Another thing you can do, is from your CentOS server in DMZ, use mail command (example below) to send email. Then look at the message header to determine which server message was routed from and use that instead of your Exchange server.