Enabling RequireTLS on Exchange Send Connectors
-
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
@scottalanmiller said in Enabling RequireTLS on Exchange Send Connectors:
Looks like only some silly home user freebie email addresses likely to be an issue. Those people all have the option of good, free secure email if they need access like that, too.
What's weird is that Cox requires the use of TLS to download your email through pop or IMAP.
No wait, that's not odd. SMTP doesn't pass credentials, IMAP does. They are protecting the log in.
-
@scottalanmiller 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:
Looks like only some silly home user freebie email addresses likely to be an issue. Those people all have the option of good, free secure email if they need access like that, too.
What's weird is that Cox requires the use of TLS to download your email through pop or IMAP.
No wait, that's not odd. SMTP doesn't pass credentials, IMAP does. They are protecting the log in.
They require logon for sending too.
-
@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:
@scottalanmiller said in Enabling RequireTLS on Exchange Send Connectors:
Looks like only some silly home user freebie email addresses likely to be an issue. Those people all have the option of good, free secure email if they need access like that, too.
What's weird is that Cox requires the use of TLS to download your email through pop or IMAP.
No wait, that's not odd. SMTP doesn't pass credentials, IMAP does. They are protecting the log in.
They require logon for sending too.
Wrong part of the connection, though. The SMTP to the other serves doesn't have the creds even if you enter them earlier.
-
@scottalanmiller 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:
@scottalanmiller said in Enabling RequireTLS on Exchange Send Connectors:
Looks like only some silly home user freebie email addresses likely to be an issue. Those people all have the option of good, free secure email if they need access like that, too.
What's weird is that Cox requires the use of TLS to download your email through pop or IMAP.
No wait, that's not odd. SMTP doesn't pass credentials, IMAP does. They are protecting the log in.
They require logon for sending too.
Wrong part of the connection, though. The SMTP to the other serves doesn't have the creds even if you enter them earlier.
I might not understand how email from a client device (like Outlook, Thunderbird) works with regards to SMTP, not MAPI/ActiveSync.
My understanding is that authentication is required to keep spammers from relaying through them.
-
Good news, 5 days so far, and only Cox.net has failed.
-
@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:
@scottalanmiller 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:
Looks like only some silly home user freebie email addresses likely to be an issue. Those people all have the option of good, free secure email if they need access like that, too.
What's weird is that Cox requires the use of TLS to download your email through pop or IMAP.
No wait, that's not odd. SMTP doesn't pass credentials, IMAP does. They are protecting the log in.
They require logon for sending too.
Wrong part of the connection, though. The SMTP to the other serves doesn't have the creds even if you enter them earlier.
I might not understand how email from a client device (like Outlook, Thunderbird) works with regards to SMTP, not MAPI/ActiveSync.
My understanding is that authentication is required to keep spammers from relaying through them.
They require credentials to relay outgoing messages to external domains, but incoming messages for cox.net the smtp server accepts without authentication.
-
spoke to soon, just people aren't reporting issues.
This is a lawfirm.
-
@brianlittlejohn 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:
@scottalanmiller 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:
Looks like only some silly home user freebie email addresses likely to be an issue. Those people all have the option of good, free secure email if they need access like that, too.
What's weird is that Cox requires the use of TLS to download your email through pop or IMAP.
No wait, that's not odd. SMTP doesn't pass credentials, IMAP does. They are protecting the log in.
They require logon for sending too.
Wrong part of the connection, though. The SMTP to the other serves doesn't have the creds even if you enter them earlier.
I might not understand how email from a client device (like Outlook, Thunderbird) works with regards to SMTP, not MAPI/ActiveSync.
My understanding is that authentication is required to keep spammers from relaying through them.
They require credentials to relay outgoing messages to external domains, but incoming messages for cox.net the smtp server accepts without authentication.
Right - I understand this for normal server to server SMTP, but I'm talking about client to server SMTP.
could they be, sure, and if they are, well then SMTP doesn't need to be authenticated unless the sending side is trying to have Cox act as a relay. -
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
spoke to soon, just people aren't reporting issues.
But are people handling it with the recipient another way? If so, win.
-
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
This is a lawfirm.
With a local server not behind some spam service I bet.
-
@JaredBusch said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
spoke to soon, just people aren't reporting issues.
But are people handling it with the recipient another way? If so, win.
Well the boss just called and said - I have a problem - fix it. Sooooo, no they aren't handling it another way, at least not yet.
I've sent a message to their whois listed technical contact.
-
@JaredBusch said in Enabling RequireTLS on Exchange Send Connectors:
@Dashrender said in Enabling RequireTLS on Exchange Send Connectors:
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:
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:
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:
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:
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.
