[129346] in North American Network Operators' Group
Re: ISP port blocking practice
daemon@ATHENA.MIT.EDU (Owen DeLong)
Fri Sep 3 08:43:51 2010
From: Owen DeLong <owen@delong.com>
In-Reply-To: <14226076.567.1283492502703.JavaMail.franck@franck-martins-macbook-pro.local>
Date: Fri, 3 Sep 2010 05:22:00 -0700
To: Franck Martin <franck@genius.com>
Cc: NANOG list <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Sep 2, 2010, at 10:41 PM, Franck Martin wrote:
> Have you heard of the submission port?
>=20
Yes... Many of the idiots that block outbound 25 also block outbound 587 =
and sometimes 465.
> Why Clients of an hotel would run a MTA anyhow?
>=20
Huh? I think you misunderstand... The problem is hotels blocking people =
from submitting outbound
messages to their home MTA, not people trying to run an MTA inside their =
hotel room. NAT pretty
much guarantees running an MTA inside the hotel room is impossible in =
most circumstances.
(That might improve when IPv6 starts hitting hotel rooms, but, for now, =
it's just not there).
Yes, some hotels offer you the option of a public IP (and usually when I =
take that option, I have
fewer network problems in general. One of the reasons I tend to prefer =
Hilton brands when possible.)
Owen
> ----- Original Message -----
> From: "Jack Bates" <jbates@brightok.net>
> To: "NANOG list" <nanog@nanog.org>
> Sent: Friday, 3 September, 2010 4:08:54 PM
> Subject: Re: ISP port blocking practice
>=20
> Patrick W. Gilmore wrote:
>>> We should be seeking to stop damaging the network for ineffective =
anti spam measures (blocking outbound 25 for example) rather than to =
expand this practice to bidirectional brokenness.
>>=20
>> Since at least part of your premise ('ineffective anti-spam =
measures') has been objectively proven false to fact for many years, I =
guess we can ignore the rest of your note.
>=20
> He's right though. tcp/25 blocks are a hack. Easy man's way out.=20
> Honestly, it'd be nicer if edge or even core systems could easily =
handle=20
> higher level filtering for things like this. There's plenty of systems=20=
> that watch traffic patterns and issue blocks based on those patterns.
>=20
> I was working with a hotel today concerning just that. They were only=20=
> doing a generic 500 connections in x period, block mac. They are now=20=
> adding a tighter rule for 15 tcp/25 connections in 1 minute, block=20
> tcp/25 (or mac, doesn't matter to me). Of course, we didn't see valid=20=
> reasons for mail blasts to be leaving a hotel and 15/minute is plenty =
of=20
> grace for a normal user. At an ISP level, it would work fine, though=20=
> methods for determining exceptions would have to be planned (though =
that=20
> could easily be handled by customer classifications like everything =
else).
>=20
>> Also, just so everyone doesn't think I'm in favor of "damaging" the =
network, I would much prefer a completely open 'Net. Who wouldn't? =
Since that is not possible, we have to do what we can to damage the =
network as little as possible. Port 25 blocking is completely =
unnoticeable to something on the order of 5-nines worth of users, and =
the rest should know how to get around it with a minimum of fuss =
(including things like "ask your provider to unblock" in many cases).
>>=20
>=20
> Blocking inbound vs outbound is another story, though. Getting people =
to=20
> implement spoof protections is more useful. I'd be interested to see=20=
> your data for concluding 5-nines of users, or did you just make that =
up?
>=20
>=20
> Jack
>=20
