> On Dec 1, 2014, at 5:25 AM, Livingood, Jason
> <jason_living...@cable.comcast.com> wrote:
>
> On 11/29/14, 3:17 PM, "John Levine" <jo...@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
