Blocking Port 25 > I don't pay for crippled access

I don't pay for crippled access

said by dervari2:

---

I pay for Internet Access, not crippled internet access whereby Bellsouth decides what ports I should be able to access on other systems. Personally, I think it's absurd. However, our house is served by IFITL so I don't really have any choice of going to another provider.

---

reply to dervari2
You are exactly right, dervari.

What respondents here are missing is blocking 25 is a blunt, dumb response that creates more problems than it solves. What are visitors to your network supposed to do? Borrow your user/pass and manually config their clients just to send an email via their own SMTP?

Blocking 25 merely forces worms & mailers to be slightly more sophisticated, it doesn't make them go away. Mail servers can function on any port; 25 is the magic mail port. I've been on 26 for almost 2 years as my SMTP provider offers it specifically to get around networks that block 25 (blocking 25 is not exactly a new practice). If I can't send via my 3rd-party SMTP provider then

> outbound is not scanned for viruses (your ISP do that?)
> outbound is not logged in traffic reports generated for me by my provider (your ISP do that?)
> I would have no fall-back option should my ISP's SMTP go down (yours ever do that?)
> I would be confined to the shiotty size restrictions of my ISP
> recipients cannot ID my traffic by user@SMTP if it doesn't routinely originate through the same SMTP
> I would have to constantly re-config my clients

The correct place to ID & filter illicit traffic at is the packet level: shaping, volume/time restrictions, header sniffing, malware scanning, time-delay holding of suspect traffic, etc, etc.. Yup it takes more brains to implement & maintain but it's also WAY more effective & cheaper in the long run. Packet-level controls also provide identification of who is doing what on the network: info that network owners should be encouraged to know & respond to rather than try to block & forget.

reply to dervari2

said by dervari2:

---

I pay for Internet Access, not crippled internet access whereby Bellsouth decides what ports I should be able to access on other systems. Personally, I think it's absurd. However, our house is served by IFITL so I don't really have any choice of going to another provider.

---

reply to jap

said by jap:

---

You are exactly right, dervari.

What respondents here are missing is blocking 25 is a blunt, dumb response that creates more problems than it solves. What are visitors to your network supposed to do? Borrow your user/pass and manually config their clients just to send an email via their own SMTP?

---

reply to dervari2
i used to have a cable company that blocked alot of File shareing ports (From Bittorrent to Crapzza) So i would be Greatful that they are only blocking port 25.

btw, that cable company was Millennium digital media.

reply to fantomposter
said by fantomposter:
"No, configure their outgoing to use your ISP's SMTP server, no username or password required."

My bad: I forgot my client's authentication to it's SMTP is not the norm. I'd sure prefer everyone config'd their clients (once!) to authenticate to their chosen SMTP than be unable to talk to their SMTP unless they are on the same network. Seems terribly limiting to me. And why advocate for users having to re-config all the time? SMTP should be a controlled, buy-it-from-anyone service like anything else. This mentality of connectivity having to be married to server-based services is moldy. I get connectivity from any number of unpredictable places.

said by fantomposter:
"they have no choice because THEIR ISP will not accept email from them unless they are on their ISP's network."

You again said it better than me. But is this an intelligent architecture? Sign of a bad ISP practice, IMO. I'm arguing for increased separation of connectivity services & server services. Both the industry and user behavior long ago headed in that direction so why would trying to control traffic by crippling network capabilities be a good idea? I cannot see how that well serves longterm improvements.

The servers generate the traffic. How can port blocking be anywhere near as effective as requiring servers & server owners to deploy the controls? Remember when network admins responded to p2p traffic with port blocking? Users rapidly deployed dynamic-both-ends clients then, later, browser tunneling. It seems to me that blocking 25 just escalates the sophistication of malware & spam, thus advancing the race which will only demand more security efforts from connectivity providers.

Anyway, my SMTP practices are in the minority here, I can see that. If more ISPs block 25 it'll just push illicit traffic over to SMTP services like the one I use, not solve the problem. Makes the ISPs look like they're taking the low-route: retain the bad actors as an IP customer and restrict the freedoms of their clean customers because it's easier than buttoning up their SMTPs.

said by jap:

---

My bad: I forgot my client's authentication to it's SMTP is not the norm.

---

quote:

---

You again said it better than me. But is this an intelligent architecture? Sign of a bad ISP practice, IMO. I'm arguing for increased separation of connectivity services & server services. Both the industry and user behavior long ago headed in that direction so why would trying to control traffic by crippling network capabilities be a good idea?

---

quote:

---

The servers generate the traffic. How can port blocking be anywhere near as effective as requiring servers & server owners to deploy the controls?

---

quote:

---

Remember when network admins responded to p2p traffic with port blocking?

---

said by fantomposter:Your client is probably doing that so that their users that travel can continue to use their own smtp

There is no "they": it's a $15/yr service I bought so I could easily network jump and gain their superior services (aforementioned SMTP, + forwarding & spam ranking of inbound).

said by fantomposter:I don't like the solution of port blocking, I only accept it as the lesser of evils. There are certainly better ways but they wont work unless we all adopt secure smtp or they rewrite smtp.

How is it that sasl would need to be universally adopted to be a security benefit? I'm a bit out of my SMTP depth here, but would it not empower the SMTP server & op to detect bad traffic & perform account-specific logging, quarantine, enforcement? I'd much rather be on a network that selectively suspended services to the IP/MAC of an infected machine but continued to serve them an IP to both comm with the owner of the infected system and facilitate that user's efforts at cleanup.

said by jap: Remember when network admins responded to p2p traffic with port blocking?

to which fantomposter replied: I warned the entire company once, removed it from their machines and then terminated the employement of anyone that used it again. Only had to fire one person.

Yours was exactly the right approach and you are lucky to have the support of your managers. (Are you, perchance, the proprietor of this business as well as the IS person?) I've been embroiled in more than one forum dialog where many technically smart people advocated (and still do) a techno arms race between net users and net admin as the way to deal with net abuse. It's so much prideful folly. The net's a social commons and abuse won't ever be effectively dealt with by imposing restrictive access: the users just take that as a challenge to write better apps, then vendors write better admin tools, and on and on. There has to be an extra-net response by humans. It's why I see even less value than you do in the practice of port blocking: it frustrates legit use & does little to fix the abuse problem. Better to provide access, log behavior then go after abusers through social/legal channels after the fact. Far more effective. (which is why CanSpam is so disappointing: it legitimizes spamming biz by restricting victim's legal recourse).

OK, I'm off this soapbox. Gotta go deploy my overpriced SMTP relay box & start spamming adverts to BellSouth customers: any port from any IP!

said by jap:

---

How is it that sasl would need to be universally adopted to be a security benefit?

---

quote:

---

I'd much rather be on a network that selectively suspended services to the IP/MAC of an infected machine but continued to serve them an IP to both comm with the owner of the infected system and facilitate that user's efforts at cleanup.

---

quote:

---

(Are you, perchance, the proprietor of this business as well as the IS person?) I've been embroiled in more than one forum dialog where many technically smart people advocated (and still do) a techno arms race between net users and net admin as the way to deal with net abuse.

---

quote:

---

It's why I see even less value than you do in the practice of port blocking: it frustrates legit use & does little to fix the abuse problem.

---

reply to jap

said by jap:

---

The correct place to ID & filter illicit traffic at is the packet level: shaping, volume/time restrictions, header sniffing, malware scanning, time-delay holding of suspect traffic, etc, etc.. Yup it takes more brains to implement & maintain but it's also WAY more effective & cheaper in the long run.

---

reply to dervari2

said by dervari2:

---

I pay for Internet Access, not crippled internet access whereby Bellsouth decides what ports I should be able to access on other systems.

---

said by dervari2:

---

Personally, I think it's absurd. However, our house is served by IFITL so I don't really have any choice of going to another provider.

---

reply to nixen

said by nixen:

---

CHEAPER??? By which measure???
Computationally, which is cheaper: doing a simple discard based on blacklisted source addresses or accepting ALL emails and running them through content analyzers?

---

said by nixen: unless you are running an SMTP server (and most ISPs ToS forbids that, any way), you have no real reason to do outbound port 25 traffic past your connectivity provider's network borders.

Visitors and giving users access to the SMTP provider of their choice, as previously discussed. On private nets it depends on how many & what kind of visitors you have but ISPs should neither force their users to use only the ISP's SMTP (often crappy) nor make it difficult for my visiting users to use the SMTP already configured into their installed clients.

said by nixen: CHEAPER??? By which measure???
Computationally, which is cheaper: doing a simple discard based on blacklisted source addresses or accepting ALL emails and running them through content analyzers?

For near-term cash outlays the former, of course, which is why I said "in the long term". My dialogs here with fantomposter have me mostly convinced that blocking of 25out may be a necessary short-term evil while ISPs implement better responses to malware & spam traffic - though there's little indication that most are poised to pursue better responses.

In an ISP environment the problem of overwhelming malware traffic will not go away until net admins deploy means for automatic (read: cheap & fast) identification of + communication with users of + partial suspension of services to bad acting machines. The reason 25out blockage rubs me wrong is it's a way to put out fires at the expense of network capability. Yes, as you say, it keeps bad traffic from crossing the expensive perimeter but it does nothing to stem the flow internally - except motivate the hijackers of the already compromised machines to install a workaround for the 25block. ISPs have got to go after and try to reduce the number of compromised machines rather than turning a blind port to them.

It should be the goal of all but the most private of networks to work towards allowing users seamless movement on & off the network without disrupting functionality. There are both hidden and unforeseeable costs to neutering functionality. Eventually users will demand something that forces providers to undo their neuter and re-enter the learning curve of how to cope with the exposure. In the case of SMTP services I think that means ISPs who ignore the source of bad traffic and merely block 25out will irritate some users, loose others, gain only a window of relief from abuse, then have to play catch-up to competitors that deployed authentication + traffic analysis to clean-up their traffic. Pissed off users generate all kinds of difficult to measure & unknowable costs and diminishing the quality of life (as they should). That's why I argue for avoiding blocks as a solution; a quick fix maybe but not a solution.