ISPs that block Port 25
This list contains some of the major ISPs that block port 25 on their servers:
AT&T (can be unblocked at the request)
MindSpring
BellSouth
MSN
CableOne
NetZero
Charter
People PC
Comcast ATTBI
Sprynet
Cox
Sympatico.ca
EarthLink
Verio
Flashnet
Verizon
MediaOne
I don't know how accurate or up to date this list is, but I know that loads of residential ISPs in countries all over the World block outgoing port 25.
Yep. A lot of big ISPs already block port 25 connections from residential lines.
That breaks a few things like the sendmail command on a default *Nix setup. But you can often set it up to relay mail to the ISP server instead.
It's a bit sad that you can't run a mail server at home. But very few people really need to do that. If you have a legitimate need to run your own mail server get a cheap cloud instance or use one of the bulk mail delivery services instead.
Blocking port 25 is a sane measure to protect Internet users from the spam and phishing mail propagated by botnets. Just like how some ISPs block the Windows networking ports to protect users with mis-configured home networks.
You usually can still run a mail server on your home connection. The port 25 block usually only blocks outgoing traffic. So you can still receive incoming email on port 25. You just need to make sure that you configure your mail server to smarthost all outgoing email via your ISPs MTA.
If you've got a dynamic IP, please don't even attempt this. If somebody else gets assigned your IP before you have a chance to update the DNS, they could potentially pick up your email.
Or use fetchmail to receive it and just use the smtp of whatever mail account provider you fetch from. Get your mail under Fourth Amendment protection and get around the port 25 blocking.
I think this is irrelivant. Don't these ISPs still run SMTP servers on port 25, but they force you to use theirs? Their SMTP servers then contact other SMTP servers on port 25 to actually deliver the mail.
Yes they do. And thus botnets are forced to route via the ISPs intermediary server instead of making a direct connection to the recipient mail server. That intermediary server can apply rate limiting and blocking.
ISPs who implement blocks on port 25 and force everyone to use their mail server are able to take responsibility for the spam leaving their network.
Note, ISPs don't block ports 587 and 465, so they're not preventing you from using services like GMail etc.
Also, it is completely relevant as they have all done exactly what is being proposed in the article being discussed. ISPs in South Korea will also provide mail relays for their subscribers to use.
But this is really easy to work around. Isn't the Soth Korea arguing that all mail relays should block port 25, not just those on residential networks?
I haven't seen them say that anywhere. If they block port 25 everywhere, then they simply prevent the ability to send or receive email within South Korea. That's clearly not their plan.
The port 25 block is designed to force compromised systems to route email via controlled boxes. The fact that you can route email via controlled boxes doesn't mean you've worked around the block, it means you've been forced to do exactly what the intention was.
Maybe I've misunderstood something. I wonder how much spam is sent via compromised residential systems and how much is sent via less than perfect commercial systems?
Wow, just tested, my home ISP doesn't block outgoing TCP port 25. I thought it did.
I suppose that would be a form of non-net-neutral corporate censorship. But one could make a pretty good argument that it's a technical issue with a core protocol of the Internet. It's not really practical to send emails from your home anyway because so many servers will simply refuse to accept them from residential netblocks.
Same decree issued by telco authority here in Finland. Nice combo with the mandatory data retention laws (must use isp mail servers + isp must keep and hand out logs to authorities).
That's actually pretty sinister. I'm in Norway, and although there hasn't been any push to centralize and consolidate the e-mail servers in the name of spam, the EU data retention directive was passed here in April after lots of resistance.
I hoped that our neighbors were in a better position to fight these attacks on liberty online. Is privacy on the web really under this much pressure in Finland?
Would a better alternative not be to not allow insecure mail servers? Why don't mail server providers disallow their programs from being open relays or have IP/Username and password restrictions in place.
I configured our mail server to only accept mail from our internal work IP address and from authorised users.
Obviously mass mail providers will only be able to impose a username and password restriction but I would say the best way is to stop people producing mail software that can be open.
botnets are the source of the vast majority of spam. Not mail servers and not open relays. If a botnet program can make an outgoing port 25 connection, they can connect directly to the recipient mail server to send the spam.
Preventing them from making outgoing connections on port 25 means they have to connect to an intermediary server instead. Usually the ISPs. This makes it much easier to detect/block/rate limit them.
Most of the time however, they just give up when they can't make the outgoing port 25 connection. Or keep trying and failing.
I configured our mail server to only accept mail from our internal work IP address and from authorised users.
So if one of your office PCs catches an e-flu, it will have no trouble using your mailserver to spread spam.
The way I see it, the only way is to make SMTP authentication mandatory _everywhere_ (except perhaps on your desktop localhost, which should accept mail from you, but should be required to authenticate when pushing your outgoing mail to your upstream mailserver).
So that if one of your office PCs gets compromised the SMTP authentication is also compromised, and therefore you have the same problem. This is assuming you don't require that someone type their password everytime they send a message--that'd be ridiculous.
Yes, I imagine there is malware out there which can read smtp credentials from an infected host, but majority can't, and will just try sending out without authentication. If nothing else, resulting amount of spam is decreased severely.
OTOH, if smtp auth became mandatory, or at least widely used, malware would just adapt, and its ability to sniff out credentials would improve. Arms race and all that. So scratch my idea.
> It stops our mail server from being used as an open relay though?
From outside of your network yes. If one of the computers inside your network is infected your mail-server will happily deliver the spam mails.
> How does blocking 1 specific port stop the issue anyway?
> They can just change the port they connect on?
I don't know of any SMTP-Server that accepts E-Mail on Ports other than 25. Port 587 requires authentification before sending an E-Mail.
I thought most poeple don't accept E-Mails sent from isp-networks with dynamic ip adresseses. Maybe that's not the case and they try to reduce spam this way.
> I was offering an opinion on how to resolve those issues.
> Changing which port accepts the mail is in my opinion pointless.
Nobody changed any ports. E-Mail is still send to port 25 from mail-servers. But if you are a not a mail-server (e.g. a client in a network) you have to use the submission port and authentificate against your isp/comapany mail-server.
you can still use port 25 on your isp mail gateway but now they can filter and rate-limit your emails.
> It's like saying that most burglars come in through the back door so the government blocks everyones back door, they will just come in the front.
not really. it is good practive to only act as mailserver if you are on a static ip and mx records point to your server. none of this is fullfilled by dynamic isp ip adresses. So this just stops the unwanted practice for good.
IMHO The best way to reduce spam is to identify the problems in the current incarnation of email and design a new system that takes such problems into account.
Well, the same problems apply to postal mail, IM and phone calls, etc.
I think the two properties which a comms method needs to have a spam problem are:
1) it is inexpensive to communicate with someone
2) it is has a fixed, human-memorable "address" which can be communicated out of band (business card, verbally etc)
Once you have these two things, such lists of fixed address can accumulate and be circulated - and they can be spammed.
(2) implies that your comms method accept comms from unknown people. (1) is necessary for spammers to bother to do to use that channel to communicate with you.
I think you have to give up one or the other of these things to avoid spam. Note that (1) is a sliding scale. Physical post is significantly more expensive than email to send, and suffers less spam - but it is not non-zero.
Basically if cost of "customer acquisition" < "cost to send spam" on that comms channel, then you'll get some (if (2) is met).
[*] I suppose some heuristics to decide if it is OK for "random unknown user X" to contact me can help. But false positives are the very devil here...
Why can't I be asked the first time someone communicates with me? (This is ofc client-side spam prevention, but it should be passed upstream ideally)
However, this isn't necessary for all communications. For instance, if a communication is signed by a reputable company (bank, for instance), then don't bother asking. ISPs should keep the list of reputable companies as short as possible and, regardless, it gets rid of phishing emails.
It's trivially easy for you to greylist everything, and trawl through that everyday, and whitelist what you want and blacklist the rest. Anything whitelisted is automatically whitelisted forever. Anything blacklisted is automatically blacklisted for ever.
The problem comes when spammers forge From headers which leads to:
-1: Very many emails in the greylist everyday
-2: False positives if they use a From that you've previously accepted (ie that person gets infected)
-3: False negatives if you get a spam that you reject which was sent from an address that you really want whitelisted.
Some of the failure modes are similar to challenge-response systems.
Nothing stops you from doing greylisting today, and it can be a very effective means of stopping most spam. There are tons of software solutions for greylisting.
Some require manual approval first time. Some sends a message back to ask the sender to do something (anything from just clicking a link to entering a captcha) and relies on you to do manual approval now and again (to catch automated but valid messages).
Some just defers delivery and waits for a second delivery attempt (because most spammers practice "fire and forget" and just ignores errors). Our office mail server is in the latter category - first time someone e-mails us,a second delivery attempt needs to happen after 10 minutes for the message to get through (it's ok if there are attempts in between too, but the assumption is that most of even the few spammers that retry will go away too quickly to send another attempt after 10 minutes). It gets rid of the vast majority of our spam before our real spam filter even kicks in.
If people see a message saying "x has tried to contact you, do you wish to allow them", some of them will say yes. So spammers will continue to spam just as hard as they always have.
Also, considering how easy it would be to spoof "x", they could probably make people click "yes" a significant amount of the time.
'"get-viagra-cheap-now" has tried to contact you, do you wish to allow them'
- the spammer has just succeeded in putting their message in front of you. If you had 500 of those per day, it would constitute spam which would again need the same filtering.
Directly, it doesn't. However, I can block your certificate., or better, I can block the CA signing certificates that represent either businesses I don't want to talk to or people who don't really exist.
Whilst I don't generally believe governments should intervene in the internet, this is one area they could intervene in. They could act as a certificate authority.
Of course, CAs will make mistakes, but they can revoke certificates when things go wrong.
You can also currently block IPs, domains, URLs and specific message content. There are even globally distributed lists of such things.
This is already how we manage to block most spam on the edge. What you're proposing is just a small iteration on the existing defences. An expensive one, which wouldn't work unless you managed to get everyone doing it at the same time.
There is a proposal for a proof of work system that does not require the sender to pay direct monetary fees and does not, significantly, slow down sending emails since it can be computed while the sender is writing the email.
I can't remember what it is called, but I hope somebody else can chime in with the name.
The smart thing about it is that you can use it as a filter in your baysian spam filtering systems. That way it can be implemented gradually, with no need to cut out everybody who doesn't yet use it.
Nice, but it would impact legitimate mailing lists.
(In the 90s Bill Gates touted the idea that the recipient of the email would receive the fee, and routinely refund it to the sender for legitimate messages.)
Wouldn't using the mailing list's email address in the hashcash algorithm work? Then the mailing list's server or recipients' clients' spam filters could utilize the hashcash header, comparing it to the mailing list address in the To field.
Mailing lists could even demand a lower hash target, requiring more energy to send messages to lists. This could rate-limit flame wars, for example.
HashCash would make it more expensive for everybody to send email, not just spammers. It's also one of those things that doesn't really work unless everybody starts using it.
What are you going to do to emails without the HashCash header when 95% of the World is still sending email without it? Does it matter to anyone else what you do to those emails if you're the only one doing it?
HashCash would have some benefits, even if only a few people start using it, and would give incentives to participate: Just don't use it for a binary decision, but as one factor in your probabilistic spam filtering. And make the filter also discriminate on the amount of work put into the hash.
Spam filtering is already 99.x% effective. So you're basically increasing the cost for everyone in order to gain one extra SpamAssassin rule?
There are plenty of reasons why "Payment" anti-spam methods have been soundly debunked over the years. You're not the first one to think it's a good idea, and you probably won't be the last, but do the research yourself first into why they can't work.
It seems to me that the easiest way to reduce spam is to use proper spam filtering. My private Gmail and my work email (proprietary commercial solution) are almost entirely spam free.
We're talking about the global spam problem, not your localised end user spam problem. Even if gmails spam filter was perfect and stopped all spam (impossible), they'd still have a problem because they'd be using vast amounts of human and computing resources to do it.
Maybe at first, but I think the GP's idea is more generally to make sending spam not a viable way of making money. If end users never see spam and spam profits drop from 0.2% of email addresses or whatever they're at now to 0.000000000002% then other methods to make money will be used.
I already specified that perfection is impossible. Even if every email is routed via a human filter instead of a computer filter, there would still be mistakes.
If a spammer can't get a message through, they will keep tweaking it until they succeed.
If even 999 out of 1000 spams are blocked, they'll still keep firing.
