Educational CyberPlayGround ®

Port Blocking

8/15/2013 BITAG publishes report on Port Blocking:
Today, the Broadband Internet Technical Advisory Group (“BITAG”) announced the publication of its technical report on the subject of Port Blocking. Below is a brief summary of the report's recommendations and the full report itself can be found at:

In the networking context, ports allow different applications running on an individual computer to share a single connection to the Internet. The practice of “port blocking” is often used, among other reasons, for security purposes to prevent unwanted or harmful traffic on a network and protect users. It is also capable of preventing the use of particular applications entirely, raising concerns that port blocking has the potential to be motivated by non-technical factors or otherwise construed as such.

BITAG's report aims to address some of these concerns by documenting how port blocking works, the rationales behind it, and its implications for different segments of the Internet ecosystem. The report also recommends best practices for entities that implement port blocking. Among other things, the report recommends that:

  • ISPs should avoid port blocking unless they have no reasonable alternatives available for preventing unwanted traffic and protecting users. Further, if port blocking is deemed necessary, it should only be used for the purposes of protecting the implementing ISP's network and users.
  • ISPs that can reasonably provide users opt-out provisions or exceptions to port blocking policies should do so.
  • ISPs should publicly disclose their port blocking policies.
  • ISPs should revisit their port blocking policies on a regular basis and reassess whether the threats that required the port blocking rules continue to be relevant.
  • ISPs should make communications channels available for feedback about port blocking policies.
  • Port blocking rules of consumer devices should be user-configurable.

Trace Hollifield, Director of Enterprise Security at Bright House Networks, and Jeffrey Swinton, Director of at Verizon, were the lead editors of the report. Douglas Sicker, Executive Director of BITAG, Chair of BITAG's Technical Working Group and Endowed Professor of computer science at the University of Colorado Boulder, chaired the Port Blocking review. Kaleb Sieh, BITAG's Deputy Director, provided editorial assistance.

Questions or Comments? BITAG welcomes any questions, comments or suggestions. Please contact our Executive Director, Douglas Sicker, at or our Deputy Director, Kaleb Sieh, at


Why can't I send Email?
Port 25 is Blocked.

Port Numbers Knowledgebase

PORT NUMBERS (last updated 2008-06-13)
The port numbers are divided into three ranges:the Well Known Ports,
the Registered Ports, and the Dynamic and/or Private Ports.

  • Well Known Ports 0 throught 1023
    DCCP Well Known ports SHOULD NOT be used without IANA registration.
    The registration procedure is defined in [RFC4340], Section 19.9.
  • Registered Ports - 1024 - 49151
    DCCP Registered ports SHOULD NOT be used without IANA registration.
    The registration procedure is defined in [RFC4340], Section 19.9.
  • Dynamic and/or Private Ports 49152 - 65535
    A value of 0 in the port numbers registry below indicates that no port has been allocated.

List of frequently seen TCP and UDP ports and what they mean. The goal of this port table is to point to further resources for more information.

Blocking Port 25 by Carl Hutzler March 19, 2007
The most effective method to stopping spam is blocking it as close to the origination point as possible. And logging. Why? Well simply put, once spam is successfully injected into the mail transport infrastructure, it is very difficult for machines to tell the difference between good email (ham) and bad email (spam). Yes, we have great systems in place to try and detect the differences and filter the bad ones out, but none are perfect and false positives are always the by-product.

A quick history of Spammer Evolution (similar to the cockroach):

Spammers need IP addresses in order to originate mail. Without a machine on the internet, a spammer can not inject spam into the system.
Spammers in the old days used to purchase large address spaces and bandwidth to send mail, but antispammers got very good at blocking the subnets. So spammers turned to masking their actual connectivity by "creating" millions of IP addresses that could be used to send spam. These machines are referred to as zombies or bot nets but are
basically a windows PC infected with a virus that allows the machine to act as a proxy which is in the control of the spammer. Spammers now send the spam through one of these compromised machines
(typically a Windoze PC on a always on broadband connection) which masks their true network identity.

Most (>99%) of these infected PCs have no legitimate requirement to transmit unauthenticated email data on port 25. In an improved world, Port 25 should only be used for sending unauthenticated email data from mail server to mail server (Mail Transmission Agents - MTAs).
Mail Clients (MSAs) should always authenticate before being allowed to submit (originate) mail. Even if the client is on the server's "trusted internal network", it should be a requirement for the client to always authenticate before sending mail. Period. Clients always authenticate to read mail, why do we allow anonymous submission of mail?

I know blocking port 25 from end-user machines works well and without major side-effects. did it for a large ISP and saw the sustainable results. We then did it on behalf of most of the other ISPs in the world...we did it on our side even if the other ISPs were unable or not competent enough to do it themselves. And the result was nothing less than spectacular and sustainable.

What are the downsides to blocking Port25?
1. People on consumer broadband networks trying to run mail servers on their DHCP addresses
2. People who have web hosting (or similar) accounts that need to submit mail "off network" and their hosting company does not provide an alternative port (e.g. 587)
3. People who are using POP3 before SMTP as their authentication method (John, who created that anyway ;-)

All of the downsides are solvable:

1. ISPs can whitelist their members who run mail servers to allow port25 outbound from those hosts. Remember, this is <<1% of the population.
2. Web hosting companies can start listening for authenticated email traffic on alternative ports, like 587
3. Anyone using POP3 before SMTP should be migrating to SMTP AUTH standards. Period.


I am an engineer. And while system designs always strive for the perfect, we never let the good enough get in the way of fielding a workable solution. So if I could reduce spam by 80% and not have any impact on 99%++ of the population of internet users, I would do it.
And for the <<1% of the people who do run mail servers on their broadband connection, lets whitelist them and let them have port25
access. Have a sign-up page for the user and let them say "I need
port 25 access, please open it for me". Done.

I think everyone would be a lot happier.

Carl Hutzler