Hello All.............I have following question with respect to Exchange 2010 Mail Flow:

Often other E-Mail Servers refuse connection and does not allow e-mail delivery if the name of the SMTP Banner is different from the MX Record.  By default, the internal FQDN is the SMPT Banner. So, my question is how can we change it to match our external MX Record?  Is it safe doing so?  Would it not cause any issues with our e-mail service?

Most of your questions are answered in many places already on the internet.
The FQDN is configured on the Send Connector. Do not touch the Receive Connector.
The receive connector should stay as the internal server name, it has no effect on internal email flow, but will mean the server fails a lot of the "banner tests" on the internet. http://semb.ee/bannertesting

Simon.

Thanks for the reply.

There was nothing defined on the Send Connector so I went ahead and defined mail.domain.com.  Yet, there is no change in the scan, still get the Banner Warning.

When SMTP Servers make connections, they would be looking for Receive Connector, what is the reason behind not changing the Receive Connector.

The online scans will always fail, because they are looking at the receive connector.
Therefore the results are not viable. Use the method I have outlined in the link above to verify the banner is correct. The receive connector should not be changed because it can interfere with Exchange operations, particularly when a second Exchange server is used/introduced. As there is no benefit to changing it, leave it alone.

Simon.

Thanks for the reply.

I have made the change to Send Connector and left the Receive Connector as it is.  And as you said, online test from mxtoolbox failed.

The link you shared asks to send email to helocheck@helocheck.abuseat.org , but I am getting error while I do that of 501 5.5.4 Unrecognized Parameter

That would suggest that something is wrong with your setup.
You always get an NDR - as that is how the test site works (it rejects the email with the result of the lookup), but it should return the valid PTR. I have just tested my own server and it works fine.

That could suggest why you are having problems. The banner isn't being seen correctly by remote sites. Any number of reasons for that, such as a typo in the SMTP FQDN (a space for example isn't valid, neither is anything like http:// or / anything at the end) to something interfering with the traffic - the Cisco ASA devices do that for example.

Simon.

Thanks for the reply.

May be I am not using the right parameter.  I am not very well versed with the HELO commands.  The server is working fine with no issues.

I am using following cmdlets.  Please correct where I am wrong

telnet mail.domain.com

HELO mail.domain.com

MAIL FROM admin@domain.com

RCPT TO helocheck@helocheck.abuseat.org

This is where I get the Error "501 5.5.4 Unrecognized Parameter"

Am I doing it wrong? BTW, I am doing it directly on the server.

You are doing a telnet test. That isn't going to be a valid test because it isn't Exchange doing the sending.  

Just create a new email in Outlook, sending it to that address. Nothing else.

You will then get an NDR with the result in it.

Simon.

Thanks for the reply.

Indeed I receive message of HELO from mail.domain.com, but running the test from mxtoolbox still shows server.domain.local

It always will, for the reasons I have given in my blog post. The mxtoolbox test connects to the INCOMING receive connector and PRESUMES that the same result will be returned for outbound email, which is not the case.

Simon.

Thanks for the reply. 

Why would they do that; just to make us look bad in front of our Managers? :)

BTW, if I change the same on the INCOMING connector, what possible problems I can come across?  

That is how Microsoft have designed the product.

The test makes assumptions that are not valid. If you "correct" the Connector to pass an indepedant test that proves nothing about email delivery, then you are likely to cause problems with email flow within Exchange - particularly if you introduce another server.

If Exchange Server authentication is enabled on the Receive Connector then the only valid entries for the FQDN are the server's real FQDN, NetBIOS or Black.

I simply ignore the test as I am aware of its limitations - the test you did above is much more reliable as an indicator on email flow problems.

Simon.