OpenBSD does *not* have a variety of mostly unused ports open by default. Windows does.
OpenBSD does *not* release "features" that few people need (or even use), that later are exploited by worms or viri. Windows does (e.g. messenger service, RPC, etc.).
OpenBSD does *not* come with a built in mail client that will execute any random code sent to an inbox. Windows does.
I agree with the article's conclusions, but I am not sure I agree with their proposed remedies. I think the most appropriate thing to do (for a government) is to require the use of open protocols.
For example, if the various departments and branches of the U.S. government would stop exclusively using MS Word as their ubiquitous document exchange format, that would make a big difference. Right now, if you want to do business with the U.S. government, you pretty much have to purchase and use MS Word. Then your office needs to purchase and use MS Word. Well, as long as your Washington office is using MS Word, I guess that field office that decided to save some money by using Word Perfect ought to "upgrade" to MS Word as well. Seems the import filters for Word Perfect don't quite get the latest version of MS Word just right.
OK, you can use Open Office or Word Perfect to create your documents, but will the pagination, headers, footers, and other tid bits come out right? No. These software products cannot make a "perfect" MS Word file because they don't know how. Microsoft has not published the specs for such a file. When the import filters get close, the MS Word format (the default format that the latest version saves to) changes ever so slightly.
How about the U.S. standardize on an open document format (egads-- not SGML but maybe even Microsoft's own RTF... anything!). Then, make sure their e-mail systems, VPN protocols, encryption formats, etc. remain based on open standards. Where Microsoft (and to be fair, others) "embrace and extend"... don't allow such non-standard extensions for dealings with the government.
Yes, it means that you will not be able to run your own stand-alone mail server. Mail servers should only be run from static, fully resolvable IP addresses anyway. Some hobbyists like to run their own mail server from their homes, and I certainly appreciate the appeal to that (increased control over their 'domain', not to mention the ablitily to show off to your friends). Hobbyists need to realize that their outbound mail looks and smells like either spam or viruses, and appreciate that the operators of larger mail servers may be inclined to treat them as such. Businesses trying to run a mail server off of a consumer grade connection shouldn't be anyway. Life sucks sometimes.
Yes, blocking egress port 25 traffic makes it difficult (not impossible) to hijack an SMTP server. It can still be done by finding a wide open HTTP proxy, for example. Most viruses will be blocked, as will most do-it-yourself spam software kits. If an ISP will give you a static IP address, then there is automaticly some accountablility (you == your IP address), and it would be reasonable to open up port 25. Be prepared to have your access cut off if you run an open relay (or otherwise mis-configured server), spam, or spew virii. Life sucks sometimes.
Blocking egress port 25 ought to be standard for all residential ISPs. There is no reason for a consumer level access user to need to run their own mailserver, and in fact almost none do (on purpose). Of course, many Windows users recently were unwittingly running an SMTP engine in the form of Sobig.(?).
ISPs need to ensure that their residential customers have egress SMTP traffic restricted to their mail servers. Users needing corporate e-mail access most likely can via SMTPS or a VPN if their IT department knows what they are doing. Users need to be respectful of the fact that they are paying for a consumer level service. If you want business level service, realize this is a higher end cost for the ISP (yes, it is-- more bandwidth, possible peering issues due to ingress vs egress traffic, legal liabilities, etc.)
ISPs supplying service to businesses need to enforce the clauses in most service agreements that require the business to 'not engage in activity that will be detrimental to the network or the Internet as a whole' (or similar- IANAL). Spamming, viruses, worms, etc. need to be controlled by the business's IT department, and the ISP should trust their business clients and allow unfettered access. If a business does not know how to secure themselves, they should be contracting someone else to help them (this could include the ISP, of course). Otherwise, they deserve to be treated as a danger to the ISP, since complaints, blacklists, and reduced bandwidth could be the result of unrestricted access.
I happened to notice a show (On The Edge) on the Discovery Wings channel covering a lot of this. Not as in depth, of course, but interesting nonetheless.
Well, you could move to a hosting company that cares about security, instead of talking the talk. Otherwise, prepare to have your site defaced at some point. Sorry. It's kind of like people who complain about their house getting flooded all the time, but they live near a river. Move.
IMHO, the single greatest threat to having a site defaced is the use of insecure protocols for publishing. Let me be more specific: FTP. Most web development tools use FTP for their "publish" feature (e.g. Dreamweaver, just to pick on them). Securing FTP is a nightmare, with all the ports randomly popping up and so forth. You have to dumb down a firewall quite a bit, and having it tunnel over SSH only partialy secures it (and you still have to deal with the firewall woes).
So, an employee goes home at night, and updates his company's web site over her cable modem connection, and the 12 year old down the block running a sniffer captures the user ID and password. She then passes this information on in a chat room, and viola! The site is defaced shortly thereafter. It does not matter what OS the site is on.
Having said that, some systems are more prone to social engineering. If the server goes down due to numerous patches being applied (and the requisite reboots), a web developer might get used to the IS department resetting her password and thus more suceptable to that phone call asking for the login info. But my point is, web site defacements do not necessarily indicate the security of the OS. It is a combination of protocols used (how about only allowing SFTP?), policies, and implementation by knowledgeable admins. Unix (Linux, BSD, etc.) admins tend to be better at implementation and policy development then their Windows brethren, perhaps that is the causal connection.
Blocking egress port 25 is simply the most effective way to ensure your business does not get blacklisted. Bonus: the SoBig.F virus (and its ilk) won't work, either.
If you connect workstations to the internet (ISPs as well as almost any other business) its time to start being responsible. Use NAT. Block outgoing ports that cause trouble (for others). Be part of solution, and you'll avoid the wrath of being part of the problem. It's that simple.
I have noticed a sharp drop in spam the past few day, too. I attributed that to the recent SoBig.F craze sweeping the nation (and beyond). Is there any definative evidence?
While I am skeptical, I am also hopeful. If he has indeed been the cause of so much of the spam I have seen recently, then this ought to serve as a wake up call to anyone looking to fill his shoes.
Exactly why ISPs and businesses that give "real" IP addresses to workstations (i.e. not NATed) need to block outgoing SMTP (port 25) traffic, except to their (properly configured) SMTP server. I was deluged with these messages as well, I tracked over 75% of them to 10 IP addresses, internal workstations at the Army, Booz Allen, and ATTBI. I am lucky, I am the admin of a mail server. I was able to add those IP addresses to my own RBL, and block any future messages before the attachment was sent!
As of this evening, I had blocked several hundred messages, saving me over 50MB of bandwidth that would have been wasted. The biggest problem with content filters is you have consumed the bandwidth in order to examine the message (twice, in fact: once coming into your server, and then when it is accessed by you via POP or IMAP).
Great, you let home users (on cable modems, perhaps?) access your sensitive data via FTP? So just one teenager sniffing on the cable line now knows the user name and password to get in.
Sounds like you have done a lot to keep script kiddies happy.
Spam control with RBLs is, in fact, decentralized. There are many RBLs to choose from, and any that are too severe will not be used for long if they generate too many false positives. As a system admin, I have my choice. I use 4 RBLs right now:
spamhaus.relays.osirusoft.com
(this is a mirror of the Spamhaus Block List) Well known spam operations, and is checked hourly.
dialups.relays.osiruSoft.com
(details at OsiruSoft) This list is of DHCP IP addresses of home users (DSL, cable, dial up).
rbl.restongeek.com
I maintain this one myself for anything I want all my servers, primary and backup MX, to block
And there are many more to choose from.
I am very happy with my results, it is a pleasure to see the reports of the mail that is blocked (see my/. journal for a sample report). If I start to think maybe one of these lists is a little too severe, or someone lets me know that there are problems with one or more of the lists, I will delete it and pick another. Or maybe not. It is my choice, I want to keep down the spam on my system, for my sake as well as my clients'.
The only solutions here are some sort of VPN to the network where my SMTP server lives (at work), or else ssh to the SMTP server (which is what I actually do, but it's inconvenient).
Exactly. The admin of the SMTP server you want to use ought to use SMTP + AUTH + SSL, which would run off another port (SMTPS uses 465). So the SSL part takes care of the issues with your ISP (they won't be blocking port 465). The AUTH part keeps your work SMTP server from unauthorized use (e.g. spammers looking for an open relay). Everyone is happy. Here are some links with additional info on setting up SMTP + AUTH + SSL:
This article highlights why I have stopped using filters altogether. End-user filters address the symptom, not the cure. The problem with even the best filter is the mail is already there, taking up space, hogging bandwidth, and the filter is churning CPU cycles to hopefuly deal with it. My mail server uses 3 rbl (blacklists), and one I have programmed myself (rbl.restongeek.com). I get no false positives, and only a trickle of spam that gets through. I also get some small pleasure reviewing my server logs of the rejected mail, where the reject happened before any of the actual data was transmitted (see my/. journal for a sample).
Of the anti-spam legislation currently being proposed, the most important clauses are those that deal with forged headers and illegal use of other servers (relay rape). Once such laws are in place, blacklists will become even more effective, because spammers will have fewer places to run and hide (if they sell something from the U.S.A.).
One final piece to the solution is to get ISPs to act responsibly, and block egress traffic on port 25 for dynamic IP addresses (look up many of my previous posts for more detail on this point). Again, combined with blacklists, this will reduce spam tremendously-- not just in your inbox, but your (and your ISP's) bandwidth.
Sorry to suggest an unpopular idea, but I think this is a good move on the part of the MPAA. Let's face it, copying a DVD for a friend (of copyrighted material) is illegal. It is, even if you don't want it to be. Nothing wrong with pointing that out, either in a Slashdot post or a movie theater commercial. This is America, land of free speech. They have a message they want to get out, let 'em.
I would much prefer them to put their effort into PR rather than lobbying, anyway.
(a) Use a third party's internet domain name or third party e-mail address in identifying the point of origin or in stating the transmission path of the commercial e-mail without the third party's consent.
(b) Misrepresent any information in identifying the point of origin or the transmission path of the commercial e-mail.
(c) Fail to include in the commercial e-mail the information necessary to identify the point of origin of the commercial e-mail.
I think it is essential that these sorts of requirements be part of any anti-spam bill. While requiring that the header contain ADV: is nice for the user, what about the operator of the user's ISP? And in particular, what about the operator who runs an honest ISP, does not allow relaying through their servers, yet still gets overloaded with incorrectly directed complaints when a spam shop uses their domain in part of the forged headers? I don't see nearly enough attention paid to that concern (disclaimer: I operate an ISP).
I agree completely. Gray on white is not the most eye-strain friendly color combo. Otherwise, I thought it was a good article, with good points. But now I have a headache.
My suggestion is to leave port 25 open, but only to allow incoming mail from other SMTP servers-- and only for your local users (by definition, it will not relay mail). So how does a user relay mail (i.e. initial mail submission)? The responsible admin of the user's SMTP server has set up SMTP + AUTH + SSL on that server (or perhaps a different server altogether-- an even better idea). Now this user can send mail (i.e. relay mail, or use the server for initial mail submission-- different terms for the same thing in this case). However, other people (unauthorized people) cannot. Spammers may port scan to their heart's content, but will still be unable to relay any spam.
My server is port scanned all the time. Many have found my port 465 open, and many have found that it is running an SMTP server with SSL. However, they don't have a user name and password, and thus their attempt to spam is blocked.
What flaw of SMTP is required for all spam to be sent
The flaw is that it allows completely unauthenticated mail to be submitted. Perhaps I should have been more clear-- SMTP as it is commonly implemented is lousy. However, sys admins are lucky that the protocol has been enhanced. Using SMTP + AUTH requires a user name and password to ensure that only authorized users are using that server to send mail. Add SSL, and the user named and passwords are protected (and it uses a different port, 465).
As noted before, please see my initial post for tips on how to implement this. Most e-mail clients support these enhancements (Outook, Mozilla, IMail (Mac), etc.).
The point is that as responsible networks start to filter egress port 25 traffic, people on that network still need to send mail. If a user is not using their ISP's mail server (and there are many reasons why someone would choose not to), and the ISP is blocking outgoing port 25, then they can't send mail.
However, if that same user wishes to use a remote SMTP server (e.g. their company's server) that accepts initial mail submission on a different port (mine is set to use SMTP + AUTH + SSL, and runs on port 465), then all is well. See my previous links for tips on setting that up.
If you are running a network, it behooves you to filter outgoing port 25. SMTP is a lousy protocol, and there is no successor to replace it (anytime soon).
E-mail server admins: Please lock down your servers! Only allow initial mail submission by authorized and authenticated clients, and only allow such subissions on a port other than 25. It's not that tough, and it's your job. Do it.
I don't think a lot of readers are understanding the idea suggested in the original post. If you are an customer of a dialup ISP, use that ISP's SMTP server-- only. If you want to use someone else's SMTP server (including your own that you set up somewhere), then that SMTP server ought to be configured to accept initial mail submission on a port other than 25. Your "rank and file" customers will not have a problem with this-- they will continue to use the ISP's SMTP server and all is well. For those "power users" (define as you like) that have a need for external SMTP servers, well, have them do the work (sorry-- life sucks sometimes). The ISP posts a page explaining why port 25 is blocked, and suggests using alternate ports (e.g. 465, SMTPS).
If you are the admin of an SMTP server that external clients (i.e. unknown IP addresses) will connect to for intitial mail submission, you are doing the Internet (and your users) a disservice if such connections are allowed unauthenticated. Sendmail, QMail, Exchange (gasp!) all can be configured to require authentication for initial mail submission. Use SSL as well, and you will probably be using another port (465). Spammers are not going to port scan for a way to send mail! Admins-- get off your butts and secure your servers, or else you are part of the spam problem. Please don't gripe about how following industry standard practices for securing a publicly accessable server makes your job more difficult-- that is your job!
In particular, what does this mean for Microsoft? From the Media Player 9 licence agreement:
You may not disclose the results of any benchmark test of the.NET Framework component of the OS Components to any third party without Microsoft's prior written approval.
So if the media player chews up more CPU than WinAmp, I can't tell my friends?
Re:This is good, but..
on
Spammers Busted
·
· Score: 2, Informative
Simple solution: have ISP's block egress traffic on port 25. Use your ISP's SMTP server, or get the admin of the server you wish to use to use a different port (e.g. SMTP + SSL on port 465). Imagine the spam that would be stopped if just AOL implemented this!
Slashdot Mirror
No-- not fair.
OpenBSD does *not* have a variety of mostly unused ports open by default. Windows does.
OpenBSD does *not* release "features" that few people need (or even use), that later are exploited by worms or viri. Windows does (e.g. messenger service, RPC, etc.).
OpenBSD does *not* come with a built in mail client that will execute any random code sent to an inbox. Windows does.
I agree with the article's conclusions, but I am not sure I agree with their proposed remedies. I think the most appropriate thing to do (for a government) is to require the use of open protocols.
For example, if the various departments and branches of the U.S. government would stop exclusively using MS Word as their ubiquitous document exchange format, that would make a big difference. Right now, if you want to do business with the U.S. government, you pretty much have to purchase and use MS Word. Then your office needs to purchase and use MS Word. Well, as long as your Washington office is using MS Word, I guess that field office that decided to save some money by using Word Perfect ought to "upgrade" to MS Word as well. Seems the import filters for Word Perfect don't quite get the latest version of MS Word just right.
OK, you can use Open Office or Word Perfect to create your documents, but will the pagination, headers, footers, and other tid bits come out right? No. These software products cannot make a "perfect" MS Word file because they don't know how. Microsoft has not published the specs for such a file. When the import filters get close, the MS Word format (the default format that the latest version saves to) changes ever so slightly.
How about the U.S. standardize on an open document format (egads-- not SGML but maybe even Microsoft's own RTF... anything!). Then, make sure their e-mail systems, VPN protocols, encryption formats, etc. remain based on open standards. Where Microsoft (and to be fair, others) "embrace and extend"... don't allow such non-standard extensions for dealings with the government.
Yes, it means that you will not be able to run your own stand-alone mail server. Mail servers should only be run from static, fully resolvable IP addresses anyway. Some hobbyists like to run their own mail server from their homes, and I certainly appreciate the appeal to that (increased control over their 'domain', not to mention the ablitily to show off to your friends). Hobbyists need to realize that their outbound mail looks and smells like either spam or viruses, and appreciate that the operators of larger mail servers may be inclined to treat them as such. Businesses trying to run a mail server off of a consumer grade connection shouldn't be anyway. Life sucks sometimes.
Yes, blocking egress port 25 traffic makes it difficult (not impossible) to hijack an SMTP server. It can still be done by finding a wide open HTTP proxy, for example. Most viruses will be blocked, as will most do-it-yourself spam software kits. If an ISP will give you a static IP address, then there is automaticly some accountablility (you == your IP address), and it would be reasonable to open up port 25. Be prepared to have your access cut off if you run an open relay (or otherwise mis-configured server), spam, or spew virii. Life sucks sometimes.
Blocking egress port 25 ought to be standard for all residential ISPs. There is no reason for a consumer level access user to need to run their own mailserver, and in fact almost none do (on purpose). Of course, many Windows users recently were unwittingly running an SMTP engine in the form of Sobig.(?).
ISPs need to ensure that their residential customers have egress SMTP traffic restricted to their mail servers. Users needing corporate e-mail access most likely can via SMTPS or a VPN if their IT department knows what they are doing. Users need to be respectful of the fact that they are paying for a consumer level service. If you want business level service, realize this is a higher end cost for the ISP (yes, it is-- more bandwidth, possible peering issues due to ingress vs egress traffic, legal liabilities, etc.)
ISPs supplying service to businesses need to enforce the clauses in most service agreements that require the business to 'not engage in activity that will be detrimental to the network or the Internet as a whole' (or similar- IANAL). Spamming, viruses, worms, etc. need to be controlled by the business's IT department, and the ISP should trust their business clients and allow unfettered access. If a business does not know how to secure themselves, they should be contracting someone else to help them (this could include the ISP, of course). Otherwise, they deserve to be treated as a danger to the ISP, since complaints, blacklists, and reduced bandwidth could be the result of unrestricted access.
I happened to notice a show (On The Edge) on the Discovery Wings channel covering a lot of this. Not as in depth, of course, but interesting nonetheless.
Well, you could move to a hosting company that cares about security, instead of talking the talk. Otherwise, prepare to have your site defaced at some point. Sorry. It's kind of like people who complain about their house getting flooded all the time, but they live near a river. Move.
At least, not always
IMHO, the single greatest threat to having a site defaced is the use of insecure protocols for publishing. Let me be more specific: FTP. Most web development tools use FTP for their "publish" feature (e.g. Dreamweaver, just to pick on them). Securing FTP is a nightmare, with all the ports randomly popping up and so forth. You have to dumb down a firewall quite a bit, and having it tunnel over SSH only partialy secures it (and you still have to deal with the firewall woes).
So, an employee goes home at night, and updates his company's web site over her cable modem connection, and the 12 year old down the block running a sniffer captures the user ID and password. She then passes this information on in a chat room, and viola! The site is defaced shortly thereafter. It does not matter what OS the site is on.
Having said that, some systems are more prone to social engineering. If the server goes down due to numerous patches being applied (and the requisite reboots), a web developer might get used to the IS department resetting her password and thus more suceptable to that phone call asking for the login info. But my point is, web site defacements do not necessarily indicate the security of the OS. It is a combination of protocols used (how about only allowing SFTP?), policies, and implementation by knowledgeable admins. Unix (Linux, BSD, etc.) admins tend to be better at implementation and policy development then their Windows brethren, perhaps that is the causal connection.
Blocking egress port 25 is simply the most effective way to ensure your business does not get blacklisted. Bonus: the SoBig.F virus (and its ilk) won't work, either.
If you connect workstations to the internet (ISPs as well as almost any other business) its time to start being responsible. Use NAT. Block outgoing ports that cause trouble (for others). Be part of solution, and you'll avoid the wrath of being part of the problem. It's that simple.
I have noticed a sharp drop in spam the past few day, too. I attributed that to the recent SoBig.F craze sweeping the nation (and beyond). Is there any definative evidence?
While I am skeptical, I am also hopeful. If he has indeed been the cause of so much of the spam I have seen recently, then this ought to serve as a wake up call to anyone looking to fill his shoes.
Exactly why ISPs and businesses that give "real" IP addresses to workstations (i.e. not NATed) need to block outgoing SMTP (port 25) traffic, except to their (properly configured) SMTP server. I was deluged with these messages as well, I tracked over 75% of them to 10 IP addresses, internal workstations at the Army, Booz Allen, and ATTBI. I am lucky, I am the admin of a mail server. I was able to add those IP addresses to my own RBL, and block any future messages before the attachment was sent!
As of this evening, I had blocked several hundred messages, saving me over 50MB of bandwidth that would have been wasted. The biggest problem with content filters is you have consumed the bandwidth in order to examine the message (twice, in fact: once coming into your server, and then when it is accessed by you via POP or IMAP).
Great, you let home users (on cable modems, perhaps?) access your sensitive data via FTP? So just one teenager sniffing on the cable line now knows the user name and password to get in.
Sounds like you have done a lot to keep script kiddies happy.
Spam control with RBLs is, in fact, decentralized. There are many RBLs to choose from, and any that are too severe will not be used for long if they generate too many false positives. As a system admin, I have my choice. I use 4 RBLs right now:
- spamhaus.relays.osirusoft.com
- dialups.relays.osiruSoft.com
- dnsbl.njabl.org
- rbl.restongeek.com
And there are many more to choose from. I am very happy with my results, it is a pleasure to see the reports of the mail that is blocked (see my(this is a mirror of the Spamhaus Block List) Well known spam operations, and is checked hourly.
(details at OsiruSoft) This list is of DHCP IP addresses of home users (DSL, cable, dial up).
(extensive details of what's on this list)
I maintain this one myself for anything I want all my servers, primary and backup MX, to block
This article highlights why I have stopped using filters altogether. End-user filters address the symptom, not the cure. The problem with even the best filter is the mail is already there, taking up space, hogging bandwidth, and the filter is churning CPU cycles to hopefuly deal with it. My mail server uses 3 rbl (blacklists), and one I have programmed myself (rbl.restongeek.com). I get no false positives, and only a trickle of spam that gets through. I also get some small pleasure reviewing my server logs of the rejected mail, where the reject happened before any of the actual data was transmitted (see my /. journal for a sample).
Of the anti-spam legislation currently being proposed, the most important clauses are those that deal with forged headers and illegal use of other servers (relay rape). Once such laws are in place, blacklists will become even more effective, because spammers will have fewer places to run and hide (if they sell something from the U.S.A.).
One final piece to the solution is to get ISPs to act responsibly, and block egress traffic on port 25 for dynamic IP addresses (look up many of my previous posts for more detail on this point). Again, combined with blacklists, this will reduce spam tremendously-- not just in your inbox, but your (and your ISP's) bandwidth.
Sorry to suggest an unpopular idea, but I think this is a good move on the part of the MPAA. Let's face it, copying a DVD for a friend (of copyrighted material) is illegal. It is, even if you don't want it to be. Nothing wrong with pointing that out, either in a Slashdot post or a movie theater commercial. This is America, land of free speech. They have a message they want to get out, let 'em.
I would much prefer them to put their effort into PR rather than lobbying, anyway.
Section 4 of the bill covers this:
I think it is essential that these sorts of requirements be part of any anti-spam bill. While requiring that the header contain ADV: is nice for the user, what about the operator of the user's ISP? And in particular, what about the operator who runs an honest ISP, does not allow relaying through their servers, yet still gets overloaded with incorrectly directed complaints when a spam shop uses their domain in part of the forged headers? I don't see nearly enough attention paid to that concern (disclaimer: I operate an ISP).
I agree completely. Gray on white is not the most eye-strain friendly color combo. Otherwise, I thought it was a good article, with good points. But now I have a headache.
My suggestion is to leave port 25 open, but only to allow incoming mail from other SMTP servers-- and only for your local users (by definition, it will not relay mail). So how does a user relay mail (i.e. initial mail submission)? The responsible admin of the user's SMTP server has set up SMTP + AUTH + SSL on that server (or perhaps a different server altogether-- an even better idea). Now this user can send mail (i.e. relay mail, or use the server for initial mail submission-- different terms for the same thing in this case). However, other people (unauthorized people) cannot. Spammers may port scan to their heart's content, but will still be unable to relay any spam.
My server is port scanned all the time. Many have found my port 465 open, and many have found that it is running an SMTP server with SSL. However, they don't have a user name and password, and thus their attempt to spam is blocked.
The flaw is that it allows completely unauthenticated mail to be submitted. Perhaps I should have been more clear-- SMTP as it is commonly implemented is lousy. However, sys admins are lucky that the protocol has been enhanced. Using SMTP + AUTH requires a user name and password to ensure that only authorized users are using that server to send mail. Add SSL, and the user named and passwords are protected (and it uses a different port, 465).
As noted before, please see my initial post for tips on how to implement this. Most e-mail clients support these enhancements (Outook, Mozilla, IMail (Mac), etc.).
The point is that as responsible networks start to filter egress port 25 traffic, people on that network still need to send mail. If a user is not using their ISP's mail server (and there are many reasons why someone would choose not to), and the ISP is blocking outgoing port 25, then they can't send mail.
However, if that same user wishes to use a remote SMTP server (e.g. their company's server) that accepts initial mail submission on a different port (mine is set to use SMTP + AUTH + SSL, and runs on port 465), then all is well. See my previous links for tips on setting that up.
If you are running a network, it behooves you to filter outgoing port 25. SMTP is a lousy protocol, and there is no successor to replace it (anytime soon).
E-mail server admins: Please lock down your servers! Only allow initial mail submission by authorized and authenticated clients, and only allow such subissions on a port other than 25. It's not that tough, and it's your job. Do it.
There, no excuses.
Sorry, but that is not a similar situation. Not even close.
I don't think a lot of readers are understanding the idea suggested in the original post. If you are an customer of a dialup ISP, use that ISP's SMTP server-- only. If you want to use someone else's SMTP server (including your own that you set up somewhere), then that SMTP server ought to be configured to accept initial mail submission on a port other than 25. Your "rank and file" customers will not have a problem with this-- they will continue to use the ISP's SMTP server and all is well. For those "power users" (define as you like) that have a need for external SMTP servers, well, have them do the work (sorry-- life sucks sometimes). The ISP posts a page explaining why port 25 is blocked, and suggests using alternate ports (e.g. 465, SMTPS).
If you are the admin of an SMTP server that external clients (i.e. unknown IP addresses) will connect to for intitial mail submission, you are doing the Internet (and your users) a disservice if such connections are allowed unauthenticated. Sendmail, QMail, Exchange (gasp!) all can be configured to require authentication for initial mail submission. Use SSL as well, and you will probably be using another port (465). Spammers are not going to port scan for a way to send mail! Admins-- get off your butts and secure your servers, or else you are part of the spam problem. Please don't gripe about how following industry standard practices for securing a publicly accessable server makes your job more difficult-- that is your job!
Simple solution: have ISP's block egress traffic on port 25. Use your ISP's SMTP server, or get the admin of the server you wish to use to use a different port (e.g. SMTP + SSL on port 465). Imagine the spam that would be stopped if just AOL implemented this!