ISP port blocking practice

Jack Bates jbates at
Fri Sep 3 04:08:54 UTC 2010

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.
> 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.

He's right though. tcp/25 blocks are a hack. Easy man's way out. 
Honestly, it'd be nicer if edge or even core systems could easily handle 
higher level filtering for things like this. There's plenty of systems 
that watch traffic patterns and issue blocks based on those patterns.

I was working with a hotel today concerning just that. They were only 
doing a generic 500 connections in x period, block mac. They are now 
adding a tighter rule for 15 tcp/25 connections in 1 minute, block 
tcp/25 (or mac, doesn't matter to me). Of course, we didn't see valid 
reasons for mail blasts to be leaving a hotel and 15/minute is plenty of 
grace for a normal user. At an ISP level, it would work fine, though 
methods for determining exceptions would have to be planned (though that 
could easily be handled by customer classifications like everything else).

> 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).

Blocking inbound vs outbound is another story, though. Getting people to 
implement spoof protections is more useful. I'd be interested to see 
your data for concluding 5-nines of users, or did you just make that up?


More information about the NANOG mailing list