While there is a setting inside the MTA to adjust this knowing you are using EOP (or any 3rd-party app in that niche) means it won't make any difference. The world is not connecting to your MTA; the world is connecting to EOP thus the banner is what EOP presents. You'll need to contact MS support for EOP.
NB: EMC:Server Config:Props on <Receive connector in question>: General tab. Halfway down is "Specify the FQDN this connector will provide in response to HELO or EHLO" From: [email protected] To: [email protected] Subject: [Exchange] RE: MTA Banner Date: Wed, 30 Jul 2014 14:54:31 +0000 Michael, Ok, makes sense. But I would still need to fix the MTA banner issue. Our 2 Exchange servers are both running HUB, CAS, MBX roles and according to TechNet I cannot change the FQDN so easily. >From Technet: If the Send connector is configured on a Hub Transport server that also has the Mailbox server role installed, any value that you specify for the Fqdn parameter isn't used. Instead, the FQDN of the server that's displayed by using the Get-ExchangeServer cmdlet is always used. For servers that have both the Hub Transport server role and the Mailbox server role installed, the only way to remove the server name from the Received: headers of the outgoing message is to use the Remove-ADPermission cmdlet to remove the Ms-Exch-Send-Headers-Routing permission from the security principals that use the connector. This action will remove all the Received: headers from the message as the message leaves the Hub Transport server. We recommend that you don't remove the Received: headers for internal messages, because the Received: headers are used for maximum hop count calculations. For more information about theRemove-ADPermission cmdlet So should I run something along these lines: Get-SendConnector "MyPartner_SendConnector" | Remove-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-Send-Headers-Routing" To me it seems running this command would just remove headers and not solve the problem (ie MTA banner must equal certificate CN) Thank you. From: [email protected] [mailto:[email protected]] On Behalf Of Michael B. Smith Sent: Wednesday, July 30, 2014 4:27 PM To: [email protected] Subject: [Exchange] RE: MTA Banner You have to create a specific send connector for this partner and you must directly connect to that partner (I.e., don’t use EOP for them). From: [email protected] [mailto:[email protected]] On Behalf Of Thomas Capacci Sent: Wednesday, July 30, 2014 9:56 AM To: [email protected] Subject: [Exchange] MTA Banner Hi, A partner organization wants to secure email flow with TLS with us. They send me the result of their testing: The MTA cannot be validated if the CN subject of the certificate doesn't match the banner of the mail gateway or the rdns entry. To resolve this issue the banner of the mail gateway must be renamed to match the CN subject of the certificate or a new certificate must be installed. MessageLabs cannot configure an Enforced TLS connection if the MTA cannot be validated. We have a 2 node DAG (Exchange 2010 Sp2 UR5) running behind a TMG 2010 server, all outbound/inbound emails are passing through Exchange Online Protection. Where exactly should I rename the banner? Some TechNet posts points to both the FQDN used in Exchange Send and Receive connectors (Property: Specify the FQDN this connector will provide in response to HELO or EHLO). For now the values are serverhostname.corp.acme.local, so I guess I should change it on all send/receive connectors to the same used in our SSL certificate which is webmail.acme.com Confusion comes from the fact we use EOP so I am not sure if changing the FQDN on our Exchange hosts will change anything as all traffic is redirected to EOP servers for outbound/inbound spam inspection. Thank you.
