Re: Configure Incoming OPTIONAL TLS on Exchange

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

You could assign an extra IP address to the server and assign the virtual
servers to the appropriate addresses.
--
Ed Crowley
MVP - Exchange
"Protecting the world from PSTs and brick backups!"

"Elroyskimms" <elroyskimms@xxxxxxxxx> wrote in message
news:1157772178.606072.121040@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I've forwarded Ben's comments to our e-mail provider and I'm hoping
they'll get this figured out. Initially, the Exchange hosting company
shared your thought that enabling TLS required it for all messages,
instead of offering it as an available option.

I'm just a lowly end user in this scenario but I can't imagine that in
order to support an emerging standard, you have to completely cut-off
all other traffic that doesn't comply. That seems a bit short-sighted
to me.

I'd considered the dual VS solution (great minds think alike???), but
the problem is that sending servers wouldn't know which VS was which.
For web browsing, the plain text standard is port 80 and the enrypted
standard is port 443. If you want encryption (and it is offered), you
know which port to communicate with. The problem with TLS is that there
isn't a standard port that sending servers would "know" to use. The
"best" solution is to assign different IP's to each VS and then list
them both as MX records and hope/pray/cross your fingers/sacrifice
small farm animals to the web gods in the hope that the sending server
attempts to communicate with the 2nd server after the first server
rejects the TLS connection attempt. But, I don't think a reliable
communication strategy should be based on the hope that the sending
server will properly handle the first rejection. That seems doomed to
fail.

I can't imagine there is no middle ground in this, but I might be
wrong. Lets hope that the powers that be provided an optional TLS
interface instead of the all or nothing approach.



.

Quantcast