On Dec 1, 2014, at 5:25 AM, Livingood, Jason <Jason_Livingood@cable.comcast.com> wrote:
On 11/29/14, 3:17 PM, "John Levine" <johnl@iecc.com> wrote:
PS: I know enough technical people at Comcast that I would be extremely surprised if it were Comcast doing this. There's plenty not to like about the corporation, but the technical staff are quite competent.
Thanks, John! I can tell folks here unequivocally that (1) the recent press article on STARTTLS re-writing did *not* involve Comcast and (2) Comcast does not engage in the claimed practice. In fact, weąre supporters and early deployers of STARTTLS on our own mail service.
I do not know how to explain the issue reported on this list. Absent a packet capture it is impossible for me to analyze this further. If anything, I could only imagine it was a misconfiguration someplace, but I have no idea where or in what network element thatąd even be possible. Iąm happy to work with anyone that has more info to try to troubleshoot this.
- Jason Livingood Comcast
I have encountered similar issues on some hotel networks. Usually, a well meaning, but severely misinformed hotel administrator decides that: 1. People don’t know what they’re doing and configure they’re laptops to use their [corporate|home|usual] mailserver even when they’re on the road, often without authentication. 2. Debugging people’s laptops for them takes a lot of time and reduces customer satisfaction. so 3. Let’s just redirect all port 25/587 to our own local SMTP proxy which can’t possibly support TLS because we don’t have all the right certificates (nor should we), so it won’t announce the STARTLES capability. I don’t know if that’s what happened in this case, because, as you say, without first-hand information and packet-captures, it’s impossible to tell, but I will say that if you intend to use TLS, make sure your MUA REQUIRES TLS, rather than preferring TLS when available (as is default on many MUAs, unfortunately). Owen