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...
-
Well, I don't know what the IP was that my spam filter hated 2 years ago, but the current IP belonging to this email server claims it in my own city, belonging to Cox Communications.
Well so much for getting it fixed.
-
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
Well, I don't know what the IP was that my spam filter hated 2 years ago, but the current IP belonging to this email server claims it in my own city, belonging to Cox Communications.
Well so much for getting it fixed.
You are conflating issues. Just because their ISP is Cox, does not mean that they are using Cox email servers.
-
@JaredBusch said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
Well, I don't know what the IP was that my spam filter hated 2 years ago, but the current IP belonging to this email server claims it in my own city, belonging to Cox Communications.
Well so much for getting it fixed.
You are conflating issues. Just because their ISP is Cox, does not mean that they are using Cox email servers.
LOL - thanks JB, I know that. I did a lookup on the IP belonging to their mx record. That IP belongs to Cox. Now while it's reasonable to assume that their ISP is Cox I never said it was cox... only that their email server is on a cox IP address.
Now, your post has made me realized I jumped the gun and assumed that a Cox IP address meant it was a Cox SMTP server, and I might very well be in error on that... checking now.
-
@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.
-
@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.
-
@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.
Pretty much all businesses had this problem. Think about how often VPNs and MPLS and similar things exist. Very common. Think about any user that has a VPN connection at home, all use of VPN causes the issue. The use of VPNs specifically to disrupt GEO IP is semi-new, but the use of all VPN does it even when not intended and if anything, VPN usage is decreasing a lot as it is rarely needed today like it was in the past. In the early 2000s VPN use was extremely high.
-
per request.
So I can plainly say that Cox.net does not support startTLS, and they have told me plainly that they never will.
Additionally, we have run into a bank, a union and a law office that didn't work by default. The bank and law office both indicated that they believed they had opportunistic TLS enabled - I showed them the telnet IP 25 output that disagrees with them. Both of these also have said they are working to make exceptions for my domain/email server/IP specifically to enable this (why???? why not just enable opportunistic TLS?) I haven't heard from the union yet.
-
@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.
-
@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"
