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