***** ***** offers a full email service for $20 per year. For this
price, you will receive 10 GB of storage and 300 email accounts.
You need your own domain to take advantage of this offer.
They have POP/IMAP and bypass ISP port 25 blocking!
This is very important for some, especially when using an old
email client on an unsupported operating system.
The ISPs don't block those ports (25 is just one of them), they are just not connected to their email server/service anymore. Instead they have opened
up the SSL variants of them. And for a good reason.
ISPs are trying to prevent non-business customers from running their own SMTP server (TCP port 25) to spam the world.
Mr. Man-wai Chang,
ISPs are trying to prevent non-business customers from running their own
SMTP server (TCP port 25) to spam the world.
I'm not sure how blocking that port would block spamming, as using the equivalent SSL port for it would also work.
AFAICT the usage of SSL connections has the same reason as always : snooping gets harder (for one, the users authentication cannot be sniffed anymore).
Though I did hear, long ago, that some ISPs routed the SMTP port connections (standard and SSL) only to their own email servers. For the reason you described.
Regards,
Rudy Wieser
I doubt it. It would mean that noone can use another email server than the one the ISP offers - if it offers one to begin with that is.
Paul,
The protocol is blocked by the ISP DPI box.
I doubt it. It would mean that noone can use another email server than the one the ISP offers - if it offers one to begin with that is.
Regards,
Rudy Wieser
I doubt it. It would mean that noone can use another email server than
the one the ISP offers - if it offers one to begin with that is.
If a customer spammed from a ISP network, that ISP would be held responsible. :)
I believe who is blocked, is anyone from outside an ISP
attempting to use an "open" SMTP implemented inside the ISP.
If I move my server to 1.2.3.4:1025, it is the protocol
which is effectively blocked,
You're not supposed to be running *any* server on a $39.95
per month consumer plan.
If any ISP were to start emitting spam email traffic,
there are tables of spammers available for other ISPs to
block, so you would soon find that your ability to "handle
(spam) mail successfully" was blocked.
If there is a naughty thing you should not be doing,
the ISP has a filter for that.
Paul,
You're not supposed to be running *any* server on a $39.95
per month consumer plan.
Why not ? To an ISP its the ammount of data that counts. Also, having a home server for VPN access from your smartphone (and than out into the world again) is a rather accepted thing to do. Heck, the some modems/routers have build-in VPN server capabilities.
Heck, even my own internet modem has port-forwarding capabilities - for exactly that purpose.
Unlimited accounts are not unlimited.
Check the TOS. A sampling here.
Paul,
Check the TOS. A sampling here.
You have a reading problem.
I said, in the part you quoted yourself :
"To an ISP its the ammount of data that counts.".
The only thing you did is use more words.
Regards,
Rudy Wieser
The protocol is blocked by the ISP DPI box. It doesn't even matter
what port you attempt it on, Port 25 closes down just as easily
as Port 1025, if the SMTP protocol is sniffed by the DPI box
examining packet payloads.
At one time, network equipment designers would not look at a payload
for any reason. It was headers-only for analysis and transport. But
today, the DPI box examines whole packets and nothing is sacred :-)
On Mon, 2/23/2026 3:43 PM, R.Wieser wrote:Tut-tut.
Paul,
Check the TOS. A sampling here.
You have a reading problem.
I said, in the part you quoted yourself :
"To an ISP its the ammount of data that counts.".
The only thing you did is use more words.
Regards,
Rudy Wieser
Jesus, Rudy.
Ah yes, trying to use a different email provider than the one your ISP (not) offers is *ofcourse* naughty.[]
On 23/02/2026 13:36, Paul wrote:
The protocol is blocked by the ISP DPI box. It doesn't even matter
what port you attempt it on, Port 25 closes down just as easily
as Port 1025, if the SMTP protocol is sniffed by the DPI box
examining packet payloads.
At one time, network equipment designers would not look at a payload
for any reason. It was headers-only for analysis and transport. But
today, the DPI box examines whole packets and nothing is sacred :-)
I don't think this can be normal.
You absolutely NEED to be able to SMTP out your emails to your outgoing >email server.
Jesus, Rudy. Do I have to do *everything* for you???
"To answer your question, ISPs block port 25".
If you read the thread, you get some idea what restrictions
ISPs put on their service
Paul,
Jesus, Rudy. Do I have to do *everything* for you???
Jesus Paul, do I have to repeat *everything* for you???
Blocking port 25 at the ISPs border means that you cannot use another email >service than the one your ISP offers - or does *NOT* offer.
That might be acceptable in your country, but over here thats a bit of a >no-no.
--- Synchronet 3.21b-Linux NewsLink 1.2. . .
My ISP is in the process of outsourcing all its email provision, but
AFAIK are not obliging their users to use their chosen provider
service who provide something for $30 a month); Also, my hosting provider
I'm pretty sure offers email handling, and I doubt my ISP would object if
I
used that. Then there is gmail of course.
I use the email address from the ISP for service-related messages.
I have addresses used for specific purposes and I use SMTP servers
associated with the respective inbox. The connection is made to
the Submit server (port 587) per RFC 3676 instead of the SMTP port
(25).
On 2026/2/23 16:18:52, R.Wieser wrote:
[]
Ah yes, trying to use a different email provider than the one your ISP (not) >> offers is *ofcourse* naughty.[]
My ISP is in the process of outsourcing all its email provision, but
AFAIK are not obliging their users to use their chosen provider (someone posted details - I think here was included - recently of some service
who provide something for $30 a month); Also, my hosting provider I'm
pretty sure offers email handling, and I doubt my ISP would object if I
used that. Then there is gmail of course.
Adam,
I use the email address from the ISP for service-related messages.
I have addresses used for specific purposes and I use SMTP servers >>associated with the respective inbox. The connection is made to
the Submit server (port 587) per RFC 3676 instead of the SMTP port
(25).
Thanks for confirming that SMTP traffic is not, by DPI boxes or otherwise, >blocked in an ISPs network or at its border.
Another "by the way" : did you know that one of the email related RFCs >specifies that an email server should accept *all* SMTP requests, even from >people who are unknown to it ?
. . .--- Synchronet 3.21b-Linux NewsLink 1.2
John,two years, and then 15 pounds a year thereafter, which isn't a lot;
My ISP is in the process of outsourcing all its email provision, but
AFAIK are not obliging their users to use their chosen provider
Here in Europe such an "you *must* use this, and pay for it whatever they ask" forcing would get them into quite a bit of hot water with the Law.PlusNet have arranged with Greenly that it will be free for the first
Interesting, and predictable. (I do have a gmail address, though haveservice who provide something for $30 a month); Also, my hosting provider
I'm pretty sure offers email handling, and I doubt my ISP would object if >> I
used that. Then there is gmail of course.
Thanks for confirming what I've been saying to Paul.
A warning though : I just read that gmail is phasing out POP3 (and thus likely also SMTP and similar) access to it.
Regards,
Rudy Wieser
however, they've not _obliged_ their users to use Greenly even
initially.
Though I get the impression that if users want to retain their PN
addresses,
they _do_ have to;
refers exclusively to *inbound* traffic
On a related note, I haven't seen a port 25 SMTP server in many years.
They seem to have moved to port 465 or 587, depending on the encryption protocol being used.
A warning though : I just read that gmail is phasing out POP3 (and thus likely also SMTP and similar) access to it.
John,
however, they've not _obliged_ their users to use Greenly even
initially.
I was thinking about Paul's suggested case where a users SMTP traffic was not allowed to exit the ISPs area of control. (and the ISP could ofcourse control who would be able to run an email server).
The idea about forced usage came from something I read some time ago : a landlord (of appartment buildings) who dictated which ISP had to be used by its renters (which just screamed "kickback!" to me). If I'm not mistaken that case has been given to the judges to decide.
Though I get the impression that if users want to retain their PN
addresses,
they _do_ have to;
That sounds logical : a new email provider with its own domain name means that the users emails domain part needs to change too.
AFAIK the only way that would /not/ be needed is when the DNS is configured to return, for the origional ISPs domain, the IP of the email provider taking over all the origional ISP's email.
R.Wieser <address@is.invalid> wrote:
[...]
A warning though : I just read that gmail is phasing out POP3 (and thus
likely also SMTP and similar) access to it.
Well, then we'll just have to re-invent GooglePOPs/GPOPs! :-)
Explanation: In the old days, free Yahoo! e-mail accounts could not
use POP/SMTP, so a proxy named YahooPOPs! (later YPOPS!) was developed,
which did POP/SMTP on the e-mail client's side and HTTP on the other
side. Of course, like currently with the YouTube downloaders, they had
to chase each and every change which Yahoo! made on the web-side, but it worked.
Later there were back-roads to get POP/SMTP for free Yahoo! e-mail accounts, so I switched to those (and still use them for any e-mail that might arrive in those old accounts).
BTW, I don't think it's very likely that Gmail will drop POP et al,
too many people and organizations depend on it.
Yes, they might drop POP access or/and non-OAuth2 authentication, but dropping IMAP/SMTP is very unlikely IMO.
Anyway, do you have a reference for this?--
...a landlord (of appartment buildings) who dictated which ISP had to be
used
by its renters
Most definitely! That's like telling people they can only watch certain
TV stations!
AFAIK the only way that would /not/ be needed is when the DNS is
configured
to return, for the origional ISPs domain, the IP of the email provider
taking over all the origional ISP's email.
I don't think that _could_ even be done.
On 2/23/2026 3:39 PM, R.Wieser wrote:
The ISPs don't block those ports (25 is just one of them), they are
just not
connected to their email server/service anymore.-a Instead they have
opened
up the SSL variants of them.-a-a And for a good reason.
ISPs are trying to prevent non-business customers from running their own SMTP server (TCP port 25) to spam the world.
On Tue, 24 Feb 2026 00:13:22 +0000, Brian Gregory <void-invalid-dead-dontuse@email.invalid> wrote:
On 23/02/2026 13:36, Paul wrote:
The protocol is blocked by the ISP DPI box. It doesn't even matter
what port you attempt it on, Port 25 closes down just as easily
as Port 1025, if the SMTP protocol is sniffed by the DPI box
examining packet payloads.
At one time, network equipment designers would not look at a payload
for any reason. It was headers-only for analysis and transport. But
today, the DPI box examines whole packets and nothing is sacred :-)
I don't think this can be normal.
You absolutely NEED to be able to SMTP out your emails to your outgoing
email server.
All this talk about blocking SMTP, and other types of traffic, refers exclusively to *inbound* traffic, meaning traffic coming *to* a
residential or consumer location. *Outbound* traffic, to the email
server of your choice, or to any other server of your choice, has never
been the problem.
On a related note, I haven't seen a port 25 SMTP server in many years.
They seem to have moved to port 465 or 587, depending on the encryption protocol being used.
R.Wieser <address@is.invalid> wrote:
[...]
A warning though : I just read that gmail is phasing out POP3 (and thus
likely also SMTP and similar) access to it.
Well, then we'll just have to re-invent GooglePOPs/GPOPs! :-)
Explanation: In the old days, free Yahoo! e-mail accounts could not
use POP/SMTP, so a proxy named YahooPOPs! (later YPOPS!) was developed,
which did POP/SMTP on the e-mail client's side and HTTP on the other
side. Of course, like currently with the YouTube downloaders, they had
to chase each and every change which Yahoo! made on the web-side, but it >worked.
Later there were back-roads to get POP/SMTP for free Yahoo! e-mail
accounts, so I switched to those (and still use them for any e-mail that >might arrive in those old accounts).
BTW, I don't think it's very likely that Gmail will drop POP et al,
too many people and organizations depend on it.
Yes, they might drop POP access or/and non-OAuth2 authentication, but
dropping IMAP/SMTP is very unlikely IMO.
Anyway, do you have a reference for this?
John,
however, they've not _obliged_ their users to use Greenly even
initially.
I was thinking about Paul's suggested case where a users SMTP traffic was >not allowed to exit the ISPs area of control. (and the ISP could ofcourse >control who would be able to run an email server).
The idea about forced usage came from something I read some time ago : a >landlord (of appartment buildings) who dictated which ISP had to be used by >its renters (which just screamed "kickback!" to me). If I'm not mistaken >that case has been given to the judges to decide.
Though I get the impression that if users want to retain their PN
addresses,
they _do_ have to;
That sounds logical : a new email provider with its own domain name means >that the users emails domain part needs to change too.
AFAIK the only way that would /not/ be needed is when the DNS is configured >to return, for the origional ISPs domain, the IP of the email provider >taking over all the origional ISP's email.
On 2026/2/24 15:15:51, R.Wieser wrote:
John,
however, they've not _obliged_ their users to use Greenly even
initially.
I was thinking about Paul's suggested case where a users SMTP traffic was >> not allowed to exit the ISPs area of control. (and the ISP could ofcourse >> control who would be able to run an email server).
I sort of understand - though through a glass darkly, as the saying
goes. (But don't try to enlighten me!)
The idea about forced usage came from something I read some time ago : a
landlord (of appartment buildings) who dictated which ISP had to be used by >> its renters (which just screamed "kickback!" to me). If I'm not mistaken >> that case has been given to the judges to decide.
Most definitely! That's like telling people they can only watch certain
TV stations!
Though I get the impression that if users want to retain their PN
addresses,
they _do_ have to;
That sounds logical : a new email provider with its own domain name means >> that the users emails domain part needs to change too.
Yes, they're sort of subsidiary email addresses. For example, my old
Demon one was <anything I liked>@soft255.demon.co.uk; the
<user>.demon.co.uk (and I think .demon.nl) obviously belonged to Demon
(and eventually Vodafone), and eventually they stopped renewing it.
AFAIK the only way that would /not/ be needed is when the DNS is configured >> to return, for the origional ISPs domain, the IP of the email provider
taking over all the origional ISP's email.
I don't think that _could_ even be done.
[]
On 2026-02-24 02:20, Char Jackson wrote:
On Tue, 24 Feb 2026 00:13:22 +0000, Brian Gregory
<void-invalid-dead-dontuse@email.invalid> wrote:
On 23/02/2026 13:36, Paul wrote:
The protocol is blocked by the ISP DPI box. It doesn't even matter
what port you attempt it on, Port 25 closes down just as easily
as Port 1025, if the SMTP protocol is sniffed by the DPI box
examining packet payloads.
At one time, network equipment designers would not look at a payload
for any reason. It was headers-only for analysis and transport. But
today, the DPI box examines whole packets and nothing is sacred :-)
I don't think this can be normal.
You absolutely NEED to be able to SMTP out your emails to your outgoing
email server.
All this talk about blocking SMTP, and other types of traffic, refers
exclusively to *inbound* traffic, meaning traffic coming *to* a
residential or consumer location. *Outbound* traffic, to the email
server of your choice, or to any other server of your choice, has never
been the problem.
On a related note, I haven't seen a port 25 SMTP server in many years.
They seem to have moved to port 465 or 587, depending on the encryption
protocol being used.
<2.6> 2026-02-23T12:20:17.994661+01:00 Telcontar postfix 3120 - - 5FED3320F54: to=<users@lists.opensuse.org>, relay=smtp.telefonica.net[86.109.99.70]:25, delay=0.6, delays=0/0.01/0.25/0.34, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 4fKJL96Pryz16JrS)
And I am on a home IP address.
On Tue, 24 Feb 2026 21:45:50 +0100, "Carlos E.R."
<robin_listas@es.invalid> wrote:
On 2026-02-24 02:20, Char Jackson wrote:
On Tue, 24 Feb 2026 00:13:22 +0000, Brian Gregory
<void-invalid-dead-dontuse@email.invalid> wrote:
On 23/02/2026 13:36, Paul wrote:
The protocol is blocked by the ISP DPI box. It doesn't even matter
what port you attempt it on, Port 25 closes down just as easily
as Port 1025, if the SMTP protocol is sniffed by the DPI box
examining packet payloads.
At one time, network equipment designers would not look at a payload >>>>> for any reason. It was headers-only for analysis and transport. But
today, the DPI box examines whole packets and nothing is sacred :-)
I don't think this can be normal.
You absolutely NEED to be able to SMTP out your emails to your outgoing >>>> email server.
All this talk about blocking SMTP, and other types of traffic, refers
exclusively to *inbound* traffic, meaning traffic coming *to* a
residential or consumer location. *Outbound* traffic, to the email
server of your choice, or to any other server of your choice, has never
been the problem.
On a related note, I haven't seen a port 25 SMTP server in many years.
They seem to have moved to port 465 or 587, depending on the encryption
protocol being used.
<2.6> 2026-02-23T12:20:17.994661+01:00 Telcontar postfix 3120 - - 5FED3320F54: to=<users@lists.opensuse.org>, relay=smtp.telefonica.net[86.109.99.70]:25, delay=0.6, delays=0/0.01/0.25/0.34, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 4fKJL96Pryz16JrS)
And I am on a home IP address.
I can't say that I've never been to Spain, but I've never been there to inspect mail servers. Thanks for the info.
I'll let him clarify, but I think he was referring to SMTP traffic, on
port 25 or not, that was historically not allowed to *enter* the ISPs
network if it's addressed to a residential address.
It wouldn't make sense to restrict outbound traffic in that way.
That sounds logical : a new email provider with its own domain name
means that the users emails domain part needs to change too.
Usually, but not necessarily. It's normally a business decision,
rather than a technical decision.
DNS is one way, but that's an all-or-nothing approach.
There are more granular methods that are especially useful in
the case of a staggered user migration that's intended to be
transparent to the user.
Char,
I'll let him clarify, but I think he was referring to SMTP traffic, on
port 25 or not, that was historically not allowed to *enter* the ISPs >>network if it's addressed to a residential address.
I have a hard time understeanding how that would help : trying to open an >SMTP connection to a random residents 'puter will not work.
. . .--- Synchronet 3.21b-Linux NewsLink 1.2
I have a hard time understeanding how that would help : trying to open an >>SMTP connection to a random residents 'puter will not work.
No. The ISP or email service delivers to its user's mailbox and blocks
the incoming connection
On 24 Feb 2026 16:03:02 GMT, Frank Slootweg <this@ddress.is.invalid>[...]
wrote:
R.Wieser <address@is.invalid> wrote:
[...]
A warning though : I just read that gmail is phasing out POP3 (and thus >> likely also SMTP and similar) access to it.
Anyway, do you have a reference for this?
It's not really correct. Google says the POP3-change only affects a
Gmail feature called "Check mail from other accounts (POP3)", which is
where you've configured Gmail to collect email from one or more third
party email accounts in an effort to consolidate all of your email in
one place. Gmail users who don't use that feature will see no changes.
Most people probably don't use that feature. I don't.
I was thinking about Paul's suggested case where a users SMTP traffic was not allowed to exit the ISPs area of control. (and the ISP could ofcourse control who would be able to run an email server).
The idea about forced usage came from something I read some time ago : a landlord (of appartment buildings) who dictated which ISP had to be used by its renters (which just screamed "kickback!" to me). If I'm not mistaken that case has been given to the judges to decide.
Char,
I'll let him clarify, but I think he was referring to SMTP traffic, on
port 25 or not, that was historically not allowed to *enter* the ISPs
network if it's addressed to a residential address.
I have a hard time understeanding how that would help : trying to open an >SMTP connection to a random residents 'puter will not work.
In the case the residents 'puter would be infected with an email (spam) >relay it still needs to go tru the an email-server, the one of the ISP >itself or another one. Which than could detect spam runs.
Quite a while ago someone connected an email spam-relay infected laptop to >our organisations network, and it got directly slapped down down by our ISP.
But even at that time when "blocking port 25" was done I realized that a >spam email relay using a different incoming port than 25 would bypass it. >Throw in hiding the actual message in other data and you could not >filter-and-block it using (D)PI either.
Hence doing the checking/filtering on the actual email-server would be the >most effective.
It wouldn't make sense to restrict outbound traffic in that way.
I've said that several times, and mentioned the ambiguity of "block port >25", but didn't get a(ny) further explanation.
Also, outbound traffic for one ISP is another ISPs incoming traffic ...
That sounds logical : a new email provider with its own domain name
means that the users emails domain part needs to change too.
Usually, but not necessarily. It's normally a business decision,
rather than a technical decision.
Thats the other possibility I mentioned.
DNS is one way, but that's an all-or-nothing approach.
Yep.
There are more granular methods that are especially useful in
the case of a staggered user migration that's intended to be
transparent to the user.
True, but than the company would need to keep its email servers >up-and-running for the duration of the migration, Which than still ends with >the all-or-nothing approach.
Adam,
I have a hard time understeanding how that would help : trying to open an >>>SMTP connection to a random residents 'puter will not work.
No. The ISP or email service delivers to its user's mailbox and blocks
the incoming connection
I ment, outside of that kind of rigamarole. Imagine the ISP doing >absolutily nothing in that regard. How would than trying to send SMTP >traffic to a random residents 'puter work ? Most people do not run email >servers, so such an attempt would fail.
But, you've described how an ISP would intercept SMTP traffic, and put the >message into the users mailbox (the ISP has for them). Do you have any idea >on which grounds they would do that ? Something the ISP could/would do >which can't be done by the user itself perhaps ?
I have a hard time understeanding how that would help : trying to open
an SMTP connection to a random residents 'puter will not work.
I don't think any of this applies any more, or maybe it still does on
legacy ISPs that were originally designed to deliver TV signals, but
several assumptions have to be in place for any of this to work.
I know I just expanded the discussion from SMTP:25 to a bunch of
other server types, but TBH I never knew of anyone who wanted to
run their own mail server, but I knew of lots of people who wanted
to serve up a simple web page or even offer FTP services.
On 2026-02-23 12:54, Mr. Man-wai Chang wrote:
ISPs are trying to prevent non-business customers from running their own
SMTP server (TCP port 25) to spam the world.
In north america, yes. In Spain, for instance, no. here all ISPs I have tested don't block any port.
On 2/25/2026 4:25 AM, Carlos E.R. wrote:
On 2026-02-23 12:54, Mr. Man-wai Chang wrote:
ISPs are trying to prevent non-business customers from running their own >>> SMTP server (TCP port 25) to spam the world.
In north america, yes. In Spain, for instance, no. here all ISPs I have
tested don't block any port.
Possibly because the world now has huge bandwidth, and they have better methods (maybe including A.I.) to detect and catch ill-behaved customers.
I was trying to figure out how "block port 25", in all its ambiguity, would >help anyone, IPS and resident alike, with anything.
Assuming SMTP traffic :
It would not help residents, for the reason I stated (and no, UDP packets >would not get anywhere either. :-) ).
It would not help the ISP, as it itself would still need to be able to >receive port 25 trafic (pre SSL era)
It would not stop spam-relays, as they could easily choose another incoming >port and mask the data.
So, assuming that any port 25 communication to anyone but the ISP is dropped >(blocked), how does that help ? The worst you would get, when no blocking >of any kind would be applied, is some spam-relays playing ping-pong with >each other, and being slapped down when they try to target an actual email >server.
in short: either I'm missing something important, or (a blanket?) blocking >of SMTP traffic was done for another reason than the ISPs stated.
On Wed, 25 Feb 2026 08:46:31 +0100, "R.Wieser" <address@is.invalid>
wrote:
Char,
I'll let him clarify, but I think he was referring to SMTP traffic, on
port 25 or not, that was historically not allowed to *enter* the ISPs
network if it's addressed to a residential address.
I have a hard time understeanding how that would help : trying to open an
SMTP connection to a random residents 'puter will not work.
I don't think any of this applies any more, or maybe it still does on
legacy ISPs that were originally designed to deliver TV signals, but
several assumptions have to be in place for any of this to work.
No ISP meddling - the topic of this discussion
Port forwarding in place, if necessary
Appropriate server configured and listening at the target address
So it's not really a random destination. It's someone who has taken
steps to configure a server, (SMTP, HTTP, FTP, etc.), including port forwarding since nearly everyone uses NAT these days.
I don't remember now if Paul was saying his ISP still blocks any inbound ports, but my current ISP does not. The ISP that I used from 1997 to...
2012 did block quite a few well known ports, inbound only, of course,
just to make sure no one ran a server out of their home, but I'm not
there anymore so I don't know the current state of things there.
I know I just expanded the discussion from SMTP:25 to a bunch of other
server types, but TBH I never knew of anyone who wanted to run their own
mail server, but I knew of lots of people who wanted to serve up a
simple web page or even offer FTP services.
On 2026-02-24, R.Wieser <address@is.invalid> wrote:
I was thinking about Paul's suggested case where a users SMTP traffic was
not allowed to exit the ISPs area of control. (and the ISP could ofcourse
control who would be able to run an email server).
The idea about forced usage came from something I read some time ago : a
landlord (of appartment buildings) who dictated which ISP had to be used by >> its renters (which just screamed "kickback!" to me). If I'm not mistaken
that case has been given to the judges to decide.
The wording here is ambiguous. "ISP" sometimes means "Transport
provider" and in other contexts means "provider of services on top of
the transport".
If the physical network is provided by the government or a regulated
monopoly (which is the case in much of Europe), the regulations may
require them to make transport available to other providers. In that
case, the fiber termination box creates a "virtual circuit" to one of a number of service providers, and the customer's provider relationship is
with that tenant. European mobile telephone service also tends to work
that way: All the mobile providers use the same towers, owner by the (sometimes former) PTT. In the US, this is only seen at the municipal
level, and is quite rare. In many states, cities are PROHIBITED from
setting up such a system.
In the USA, the coax or fiber to the home is owned by the ISP, which is
often the Cable TV company. And if a second fiber network is built out
by someone else, the contract between the cable TV and the landlord
often spells out that no other network provider will be allowed to
acquire customers from residents in the apartment complex.
In the US, the industry as captured the regulatory system.
Or as Peter Thiel said (possibly paraphrased: "I find Liberty and
Democracy to be somewhat incompatible." Liberty meaning the freeedom of capitalists to maximize rent collection from their investments.
I'm at the edge of what I remember, so I checked Google and they
offer up other reasons for ISPs blocking ports. *shrug* ISPs not
wanting to look bad by being the source of spam, for example.
| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 59 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 24:10:01 |
| Calls: | 810 |
| Calls today: | 1 |
| Files: | 1,287 |
| D/L today: |
12 files (21,036K bytes) |
| Messages: | 195,978 |