New SMTP banner not working
The origional banner was remote.ourcompanydomain.tv I changed the SMTP banner using Set-ReceiveConnector -identity RAVEN\Default RAVEN -Banner "220 Mail.ourcompanydomain.tv" I ran Get-ReceiveConnector "RAVEN\Default RAVEN" | FL and recieved this response clearly showing the banner is now Mail.ourcompanydomain.tv but the response from a telnet mail smtp session still shows remote.ourcompanydomain.tv the old banner . I only show the first few lines of the response from Get-ReceiveConnector for brevity AuthMechanism : Tls, Integrated, BasicAuth, ExchangeS erver Banner : 220 Mail.ourcompanydomain.tv Any ideas on why the new banner won't show
July 22nd, 2011 10:00am

Did you restart transport service? Although changing the banner on the receive connector isn't always a good idea, particularly if you have multiple servers. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.
Free Windows Admin Tool Kit Click here and download it now
July 22nd, 2011 11:13am

Only one server and I restarted the Transport service with no change Larry
July 22nd, 2011 12:03pm

Why are you changing it anyway? The use of the word "remote" tends to point to SBS, as that uses that convention. SBS will attempt to change it back when some wizards are run. When it comes to SBS systems it is best to use what SBS wants to use - which is remote.example.com. Are you sure that it is Exchange answering, and not something else? Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.
Free Windows Admin Tool Kit Click here and download it now
July 22nd, 2011 2:13pm

Problem solved I changed the banner on the wrong connector. This all got started when I ran a SMTP test and the results came back that the banner did not match the Reverse DNS. Thanks for the help Larry
July 22nd, 2011 4:52pm

Exchange 2007 and higher will always fail those kinds of tests because they are testing the inbound traffic (which doesn't matter) and presuming that the server uses the same identification for outbound as well - which it doesn't. Therefore changing the banner to pass those tests does nothing to help get your email delivered and not caught in anti-spam measures is a waste of time. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.
Free Windows Admin Tool Kit Click here and download it now
July 22nd, 2011 5:48pm

On Fri, 22 Jul 2011 13:58:14 +0000, ldanna1945 wrote: > > >The origional banner was remote.ourcompanydomain.tv > >I changed the SMTP banner using > >Set-ReceiveConnector -identity RAVEN\Default RAVEN -Banner "220 Mail.ourcompanydomain.tv" > >I ran Get-ReceiveConnector "RAVEN\Default RAVEN" | FL and recieved this response clearly showing the banner is now Mail.ourcompanydomain.tv but the response from a telnet mail smtp session still shows remote.ourcompanydomain.tv the old banner . I only show the first few lines of the response from Get-ReceiveConnector for brevity AuthMechanism : Tls, Integrated, BasicAuth, ExchangeS erver Banner : 220 Mail.ourcompanydomain.tv > >Any ideas on why the new banner won't show When you try your telnet test, are you sure you're connecting to the Exchange software and not some 3rd-party anti-spam filter or SMTP proxy or relay? Try "telnet 127.0.0.1 25" from the Exchange server's keyboard. Do you have more than one Receive connector? If so, is the "Default RAVEN" the one you use to accept e-mail from the INternet?? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP
July 22nd, 2011 5:58pm

On Fri, 22 Jul 2011 20:50:12 +0000, ldanna1945 wrote: >Problem solved I changed the banner on the wrong connector. Well, I guess that answred my question about the rigt connector. :-) ?This all got started when I ran a SMTP test and the results came back that the banner did not match the Reverse DNS. On a Receive Connector? Who cares? I suppose some zealot might check the 220 SMTP banner against the results of a forward lookup of the name presented in the 220 banner, but I haven't seen that one (yet!). Your SEND connector's IP address should have a PTR record (which is the only requirement) but the name used by the send connector doesn't have to match the name in the PTR record -- unless you're dealing with people that love to misinterpret the RFCs. It's not a _bad_ idea to have the names match, though. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP
Free Windows Admin Tool Kit Click here and download it now
July 22nd, 2011 6:04pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics