[176523] in North American Network Operators' Group
Re: Transparent hijacking of SMTP submission...
daemon@ATHENA.MIT.EDU (Owen DeLong)
Wed Dec 3 12:57:54 2014
X-Original-To: nanog@nanog.org
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CAL9jLaY1q_RBkyB6kczKZUiFR5b1r3kuVz8WivWR0Rjj_oaGTg@mail.gmail.com>
Date: Wed, 3 Dec 2014 09:48:08 -0800
To: Christopher Morrow <morrowc.lists@gmail.com>
Cc: nanog list <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org
I suspect it isn=E2=80=99t comcast at all.
I suspect it is the wifi operator and they happen to use comcast as an =
upstream. The RDNS points to the public address in front of the wifi. =
The proxy doing the rewriting is likely behind that.
Owen
> On Nov 29, 2014, at 10:46 AM, Christopher Morrow =
<morrowc.lists@gmail.com> wrote:
>=20
> backing up a bit in the conversation, perhaps this is just in some
> regions of comcastlandia? I don't see this in Northern Virginia...
>=20
> $ openssl s_client -starttls smtp -connect my-mailserver.net:587
> CONNECTED(00000003)
> depth=3D0 description =3D kVjtrCL8rUdvd00q, C =3D US, CN =3D
> my-mailserver.net, emailAddress =3D my-emailaddrss.com
> verify error:num=3D20:unable to get local issuer certificate
> verify return:1
> depth=3D0 description =3D kVjtrCL8rUdvd00q, C =3D US, CN =3D =
my-mailsever.net,
> emailAddress =3D my-emailaddress.com
> verify error:num=3D27:certificate not trusted
> verify return:1
> depth=3D0 description =3D kVjtrCL8rUdvd00q, C =3D US, CN =3D
> my-mailserver.net, emailAddress =3D my-emailaddress.com
> verify error:num=3D21:unable to verify the first certificate
> verify return:1
>=20
> ...
>=20
> Certificate chain
> 0 =
s:/description=3DkVjtrCL8rUdvd00q/C=3DUS/CN=3Dmy-mailserver.net/emailAddre=
ss=3Dy-emailaddress.com
> i:/C=3DIL/O=3DStartCom Ltd./OU=3DSecure Digital Certificate
> Signing/CN=3DStartCom Class 1 Primary Intermediate Server CA
>=20
> ...
>=20
> New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol : TLSv1.2
> Cipher : ECDHE-RSA-AES256-GCM-SHA384
> Session-ID: =
FC3E47AF2A2A96BF6DE6E11F96B02A0C41A6542864271F2901F09594DE9A48FA
> Session-ID-ctx:
> Master-Key:
> =
BE7FB76EF5C0A9BA507B175026F73E67080D6442201FDF28F536FA38197A9B1353D644EEAF=
8D0D264328F94B2EF5742C
> Key-Arg : None
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> Start Time: 1417286582
> Timeout : 300 (sec)
> Verify return code: 21 (unable to verify the first certificate)
> ---
> 250 DSN
> ehlo me
> 250-my-mailserver.net
> 250-PIPELINING
>=20
>=20
> On Sat, Nov 29, 2014 at 12:26 PM, Jean-Francois Mezei
> <jfmezei_nanog@vaxination.ca> wrote:
>> On 14-11-29 11:07, Sander Steffann wrote:
>>=20
>>> I am so glad that our Dutch net neutrality laws state that =
"providers of Internet access services may not hinder or delay any =
services or applications on the Internet" (unless [...], but those =
exceptions make sense)
>>=20
>>=20
>> However, in the case of SMTP, due to the amount of spam, most ISPs =
break
>> "network neutrality" by blocking outbound port 25 for instance, and
>> their SMTP servers will block much incoming emails (spam). However,
>> SMTP is a layer or two above the network. But blocking port 25 is at =
the
>> network level.
>>=20
>> I have seen wi-fi systems where you ask to connect to 20.21.22.23 =
port
>> 25, and you get connected to 50.51.52.53 port 25. (the ISPs own SMTP
>> server). I would rather they just block it than redirect you without
>> warning to an SMTP server of their own where they can look and your
>> outbound email, pretend to acccept it, and never deliver it.
>>=20
>>=20
>>=20
