Enabling RequireTLS on Exchange Send Connectors
-
@coliver said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
@scottalanmiller said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
@JaredBusch said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
https://i.imgur.com/Z0O4DcO.png
This is a lawfirm.
With a local server not behind some spam service I bet.
That's hard to say. I do know that their SMTP out IP address was GEO tagged as coming from Europe, so my spam filter used to block them, but I have to remind myself that Geo tracking IPs is pretty unreliable these days...
Always were. Any use of a VPN completely defeats GEO IP tracking and VPNs predate GEO IP tracking. The idea that it's a new problem makes it more confusing.
it's not a new problem, but ubiquitous use of VPN by consumers is a pretty new situation so I don't think it broke all that much, businesses that ran into the issue, might have had more clout to get things resolve with paid services they used that were business services.
Hasn't HTTP over SSL been around longer then GeoIP tracking? We've had full on SSL VPNs since 1994 at least.
They have not been in common usage.
-
@coliver said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
@scottalanmiller said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
@JaredBusch said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
https://i.imgur.com/Z0O4DcO.png
This is a lawfirm.
With a local server not behind some spam service I bet.
That's hard to say. I do know that their SMTP out IP address was GEO tagged as coming from Europe, so my spam filter used to block them, but I have to remind myself that Geo tracking IPs is pretty unreliable these days...
Always were. Any use of a VPN completely defeats GEO IP tracking and VPNs predate GEO IP tracking. The idea that it's a new problem makes it more confusing.
it's not a new problem, but ubiquitous use of VPN by consumers is a pretty new situation so I don't think it broke all that much, businesses that ran into the issue, might have had more clout to get things resolve with paid services they used that were business services.
Hasn't HTTP over SSL been around longer then GeoIP tracking? We've had full on SSL VPNs since 1994 at least.
Sure, but that's not really meant to obfuscate traffic on the internet, those are meant to get traffic into a private network, so GEO IPs wouldn't really matter in most cases.
-
Well, it looks like the law firm has fixed their issue.
-
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
Well, it looks like the law firm has fixed their issue.
OK another source checked for me.. looks like they fixed their opportunistic problems.
-
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
per request.
So I can plainly say that Cox.net does not support startTLS, and they have told me plainly that they never will.
They have a vested interest in being crappy. There is no reason for them to be more than minimally functional.
-
@coliver said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
@scottalanmiller said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
@JaredBusch said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
https://i.imgur.com/Z0O4DcO.png
This is a lawfirm.
With a local server not behind some spam service I bet.
That's hard to say. I do know that their SMTP out IP address was GEO tagged as coming from Europe, so my spam filter used to block them, but I have to remind myself that Geo tracking IPs is pretty unreliable these days...
Always were. Any use of a VPN completely defeats GEO IP tracking and VPNs predate GEO IP tracking. The idea that it's a new problem makes it more confusing.
it's not a new problem, but ubiquitous use of VPN by consumers is a pretty new situation so I don't think it broke all that much, businesses that ran into the issue, might have had more clout to get things resolve with paid services they used that were business services.
Hasn't HTTP over SSL been around longer then GeoIP tracking? We've had full on SSL VPNs since 1994 at least.
Depends, yes we've had HTTPS commonly for a very long time and GeoIP detection is common only relatively recently. But in some ways, we've had GeoIP tracking since the first IPs were assigned. The first six sites were tracked by IP. So in some ways we've had GeoIP since day one. But it was long, long ago that it stopped working. Same with SS7 (PSTN). My home phone in 1997 was listed as a different city than I lived in (listed as Webster, NY; lived in Greece, NY) and my IP address was likewise off a bit.
So all networks have this issue, even ones that predate the Internet by decades. The nature of a network is that you can't know where the endpoint is.
-
My hotel room here in Dallas is coming up as Toronto as well.
-
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
@coliver said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
@scottalanmiller said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
@JaredBusch said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
https://i.imgur.com/Z0O4DcO.png
This is a lawfirm.
With a local server not behind some spam service I bet.
That's hard to say. I do know that their SMTP out IP address was GEO tagged as coming from Europe, so my spam filter used to block them, but I have to remind myself that Geo tracking IPs is pretty unreliable these days...
Always were. Any use of a VPN completely defeats GEO IP tracking and VPNs predate GEO IP tracking. The idea that it's a new problem makes it more confusing.
it's not a new problem, but ubiquitous use of VPN by consumers is a pretty new situation so I don't think it broke all that much, businesses that ran into the issue, might have had more clout to get things resolve with paid services they used that were business services.
Hasn't HTTP over SSL been around longer then GeoIP tracking? We've had full on SSL VPNs since 1994 at least.
Sure, but that's not really meant to obfuscate traffic on the internet, those are meant to get traffic into a private network, so GEO IPs wouldn't really matter in most cases.
Private network and obfuscating traffic are the same thing there.
-
Did you break your cox?
I'll get my coat and show myself out....
-
OK, we've had two sites get themselves fixed, the law firm and the bank - the both now accept TLS.
The two consumer class ISP emails - Cox.net and inebraska.com have both in no uncertain terms indicated that they will NOT support TLS.
I've been required to setup a bypass for one of them, currently it appears I can only do a bypass at a domain level, not the email address level - I'm still looking, but if you are aware of a way to add an email address bypass only to the outbound connector on Exchange 2010, please share.
-
That second one looks like a code for "drunk Nebraska"
-
That's awesome that two agreed to fix the issue.
-
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
OK, we've had two sites get themselves fixed, the law firm and the bank - the both now accept TLS.
The two consumer class ISP emails - Cox.net and inebraska.com have both in no uncertain terms indicated that they will NOT support TLS.
I've been required to setup a bypass for one of them, currently it appears I can only do a bypass at a domain level, not the email address level - I'm still looking, but if you are aware of a way to add an email address bypass only to the outbound connector on Exchange 2010, please share.
Does this not break your HIPAA compliance, as users will be able to send to this domain unencrypted? Thus defeating the entire purpose?
Tell your CEO that if you do this, then you have to pay for some third party service for secure delivery. Their call to waste the money. Not yours.
-
@scottalanmiller said in Enabling RequireTLS on Exchange Send Connectors:
That's awesome that two agreed to fix the issue.
Actually I consider it sad - When I explained the problem to one, they flat out told me - yes we do. I offered to send screen shots of the ehlo response - oh hold on... tappy tappity, tap tap.. huh.. hmm... Ok... oh .. what IP are you coming from? I tell them... more waiting.. oh ok try now... tada! it worked....
The other one responded to my original inquiry claiming that they had opportunistic enabled by default for anyone, I sent them the screen shots, an hour later - OK please try it - tada!
They are both now offering opportunistic TLS - I tried from multiple locations with different domains and they now always offer startTLS. So yeah.. they now offer a bit more security.
-
@Dashrender also they got busted running in house, insecure email. Probably a lot of unsecured things that they thought they could make a quick buck running shoddily in house.
-
@JaredBusch said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
OK, we've had two sites get themselves fixed, the law firm and the bank - the both now accept TLS.
The two consumer class ISP emails - Cox.net and inebraska.com have both in no uncertain terms indicated that they will NOT support TLS.
I've been required to setup a bypass for one of them, currently it appears I can only do a bypass at a domain level, not the email address level - I'm still looking, but if you are aware of a way to add an email address bypass only to the outbound connector on Exchange 2010, please share.
Does this not break your HIPAA compliance, as users will be able to send to this domain unencrypted? Thus defeating the entire purpose?
Tell your CEO that if you do this, then you have to pay for some third party service for secure delivery. Their call to waste the money. Not yours.
I passed along that I had to allow the entire domain at the end of the day.. she said she would think on it over night. She wasn't worried about it as long as we could limit to a single email account, but a whole domain.. yeah that's a bigger issue.
-
@scottalanmiller said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender also they got busted running in house, insecure email. Probably a lot of unsecured things that they thought they could make a quick buck running shoddily in house.
They both used external IT to manage at least their email.
-
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
@JaredBusch said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
OK, we've had two sites get themselves fixed, the law firm and the bank - the both now accept TLS.
The two consumer class ISP emails - Cox.net and inebraska.com have both in no uncertain terms indicated that they will NOT support TLS.
I've been required to setup a bypass for one of them, currently it appears I can only do a bypass at a domain level, not the email address level - I'm still looking, but if you are aware of a way to add an email address bypass only to the outbound connector on Exchange 2010, please share.
Does this not break your HIPAA compliance, as users will be able to send to this domain unencrypted? Thus defeating the entire purpose?
Tell your CEO that if you do this, then you have to pay for some third party service for secure delivery. Their call to waste the money. Not yours.
I passed along that I had to allow the entire domain at the end of the day.. she said she would think on it over night. She wasn't worried about it as long as we could limit to a single email account, but a whole domain.. yeah that's a bigger issue.
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
@JaredBusch said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
OK, we've had two sites get themselves fixed, the law firm and the bank - the both now accept TLS.
The two consumer class ISP emails - Cox.net and inebraska.com have both in no uncertain terms indicated that they will NOT support TLS.
I've been required to setup a bypass for one of them, currently it appears I can only do a bypass at a domain level, not the email address level - I'm still looking, but if you are aware of a way to add an email address bypass only to the outbound connector on Exchange 2010, please share.
Does this not break your HIPAA compliance, as users will be able to send to this domain unencrypted? Thus defeating the entire purpose?
Tell your CEO that if you do this, then you have to pay for some third party service for secure delivery. Their call to waste the money. Not yours.
I passed along that I had to allow the entire domain at the end of the day.. she said she would think on it over night. She wasn't worried about it as long as we could limit to a single email account, but a whole domain.. yeah that's a bigger issue.
I think I can restrict the connector to just those that need it, that will drastically reduce the risk. Something to try in the morning.
http://exchangeserverpro.com/restrict-outbound-email-transport-rule/
-
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
@scottalanmiller said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender also they got busted running in house, insecure email. Probably a lot of unsecured things that they thought they could make a quick buck running shoddily in house.
They both used external IT to manage at least their email.
Who was overseeing the external IT?
-
Ok - I'm waiting on final confirmation, but I'm pretty sure this is going to work.
I create a transport rule that looks for any email destine for @inebraska.com and denies the send unless you are a member of a specific group. While this still isn't perfectly locked down as I'd like (i.e. only to the single emails address on that domain), it's much better than a pure open connection.
While typing this I had another idea - sadly I can't mix them as the or operand appears to be the only option when having multiple exceptions on a rule. My thought was to only allow exceptions when sending to a specific email address and the sender being in the allowed group, but again - that darn operand.
I think allowing anyone in the company to email that one user, a user we know and trust, is better than allowing those in the allowed group to email anyone on the domain. Thoughts?
