By this, I guess you mean "End user submits mail to an SMTP server run by their ISP."
No, that is not what I meant. I meant and end user submits their mail to an SMTP server that they are authorized to use. This could be their ISP's server, or it could be their company's located in a faraway land. The point is that the act of initial mail submission needs to be on a different port than 25 (I suggest 465 for SMTP+SSL+AUTH). Now even if your ISP is blocking port 25, your IMS can still go through, since the SMTP server you want (and presumably are authorized) to use accepts IMS on port 465.
SMTP was not designed as a peer to peer protocol. It was clearly designed to have mail transport handled by duly assigned SMTP servers, as indicated by MX records in a domain's DNS zone.
Eventualy, mail being recieved from remote hosts (that is different from initial mail submission, which ought to require an AUTH step) arrives on port 25. So if there is a trojaned host somewhere accepting mail on port 25356, so be it. It will need to eventualy send that mail out to somebody's SMTP server on port 25. If the ISP is blocking such traffic, then the spam/virus/trojan is blocked.
Therefore, I don't propose anything other than blocking egress port 25 traffic.
I don't see this as a degenerating spiral at all. Port 25 is being constantly abused for purposes other than what it was designed for (SMTP transfers between properly configured MTAs). There are a few other ports that have been abused as well (135), but they are very much the exception and not the rule. People who run and manage ISPs are advocating these sorts of measures because the abuses are getting overwhelming.
SMTP allows any IP host to transfer mail to any other IP host
That's exactly the problem. Mail is not supposed to be transmitted from any IP host to any IP host. The way it is supposed to work is:
End user submits mail to their SMTP server
SMTP server queues the mail, looks up the MX hosts of the recipient, and attempts delivery (this step may take time, due to internet congestion, etc.)
Recipient's SMTP server receives the message (possibly from a backup MX host)
SMTP server delivers the message to recipient's POP/IMAP/etc. server (maybe Exchange)
Recipient accesses message using their e-mail client (Pine, Outlook, Eudora, Mozilla, etc.)
In particular, the message is not sent directly from the sender to the recipient! That won't work-- what if the recipient's workstation is off? What if the recipient uses several different computers (devices) to access their mail? SMTP was reasonably well thought out, the only problems realy are that IMS and mail transport were originaly designated to use the same port, and there was no encryption or authentication built in. Now with SMTP+SSL+AUTH, and IMS on an alternate port, it is pretty robust.
Correct, that port is a different port, used for IMS. When you add SSL (and I strongly recommend AUTH as well), the proper port is 465 (SMTPS). Or not-- nothing wrong with 587, the theory still holds. Or use port 26, as the previous post suggested.
Initial mail submission is different than mail transport!
This is getting ridiculous. All of these worms/viruses of late have their own SMTP engine built in, and connect directly to external SMTP servers to spread their payload. ISP's (and businesses that provide access to internal workstations) need to block access to external SMTP servers! In particular, block egress port 25 from the network.
So you will ask, "But then how will I use my company's or other SMTP servers from home?" Easy, the port used for initial mail submission (IMS) should be set to a different port altogether. IMS and mail transport are different activities and should be treated as such. Use SMTP+AUTH+SSL, run it on port 465, and everybody is happy (except spammers and virus authors).
"But I want to run my own server on my dial-up or other consumer level account!" Contact your ISP and see if you can get a static IP address. SMTP servers should be on static IPs, that way bounces and other system messages can be routed properly. Check the AUP of your ISP, you might be prohibited from running a server on your account (find another ISP, or use the tip above to use a different SMTP server).
To do otherwise is to continue to be part of the problem, not part of the solution.
I could not help but notice that Google, Yahoo, and Slashdot are omitted from their "top 1000" list. Yet rumors persist that these three web sites get a fair amount of traffic.
Results 1-15 of about 1136552 containing "freebsd"
Results 1-15 of about 341343 containing "openbsd"
Results 1-15 of about 200091 containing "ipsec"
Results 1-15 of about 96796 containing "postgres"
Results 1-15 of about 9641 containing "plan9"
Results 1-15 of about 408 containing "OS/2"
Results 1-15 of about 365 containing "linux"
Results 1-15 of about 113 containing "apache"
Results 1-15 of about 76 containing "php"
Results 1-15 of about 40 containing "mysql"
Clearly, those platforms that MS does not like are treated differently than less popular (and less threatening?) technologies. Or maybe Plan9 is finaly picking up steam.
No need to use your ISP's servers at all. Have the admin of the mail server you wish to use configure the server to use SMTP+AUTH on a different port. Even better, use SMTP+AUTH+SSL. No blocking, the chain of responsibility is intact, everybody is happy.
There is something wrong with using port 25 for initial mail submission. Submitting a mail message by an end user is a different activity then two SMTP servers transmitting mail to each other.
Initial mail submission is a potential security violation, and certain restraints on relaying mail are important. Here is where SSL and SMTP+AUTH make sense. The user submits the mail, and then can forget about it-- the SMTP server will now handle the rest, including queuing the message in case the remote MX host is down, etc.
Mail transport is between two SMTP servers. MX hosts are looked up, and each tried in a specified order until the message is delivered to an appropriate recieving SMTP server. In some cases, the message is queued for hours or days.
These are different activities, and ought to be handled as such. That is why the alternate ports are used for initial mail submission. While it is true that STARTTLS will work over port 25, it is a disservice to the users of that mail server to configure it that way. What about remote users who's ISP is (responsibly) blocking port 25? Or, as another poster pointed out, silently relaying all outgoing port 25 traffic to their own server? The alternate ports solve this problem quite well.
I have many clients on DSL lines, too. They have arrainged with their ISP for a static IP address, and the ISP pretty much lets them do whatever they want to. Any malicious activity, and they know where to find them.
This is certainly good news. Now their customers who are infected will figure things out pretty quickly!
Of course, this would have been easier if they just blocked egress port 25 traffic (which would not include their own SMTP server, of course!). Imagine all ISPs blocking egress port 25 traffic for their DHCP clients (e.g. most cable modem, dial-up, and DSL), and shutting off their corporate clients who spew spam! That would effectively eliminate spam, since IP addresses left still sending spam (directly or due to a trojan/virus) would quickly end up on DNSBLs.
It is irresponsible for ISPs to operate otherwise. Simple steps to be a good netizen:
Don't use port 25 for initial mail submission. The fact that this port is used for both mail transport (between systems) and initial mail submission (which is really a different activity if you think about it) is a mistake. Use port 587 with SMTP+AUTH, or port 465 with SMTP+AUTH+SSL
Implement one of the reverse lookups for incoming SMTP traffic (RMX or SPF:Sender) when one of the competing proposals become a standard (and your software catches up)
Block egress port 25 traffic from your network
These apply to any businesses that supplies IP connectivity to any other computers (offices, schools, WISPs, in addition to standard ISPs). To not do so is to be a part of the problem.
While it is true that some DNSBLs block entire netblocks, those lists are used by the fewest people. There are a great many DNSBLs one can use to block mail, some are maintained better than others and most have different criteria for inclusion and removal. Use the ones that match your philosophical opinion of spam, don't use the ones that you feel are too extreme.
It looks like this is a bit more specific than the original post would lead one to believe. It does not cover installing software remotely. This patent is more about saving a user's settings remotely, then transferring them to a new computer. Looks like it is a way to facilitate the use of a remote IT staff. It does not look like it covers downloading software install packs, nor does it seem to cover software updates. But hey, IANAL:)
That's not the way the particular spam you mention works, correct. But the online pharmacies, stock pump-n-dump schemes, porn, 'work-at-home' and other spam messages generaly have a U.S. component to them that gets the cash eventualy.
If this bill could just eliminate spam for anti-spam software I would consider it a success.
Yes, the spam mostly comes from IP addresses outside the U.S. However, it is almost always advertising something sold by an entity in the U.S.
This bill, if passed, can have an effect. If a company in the U.S. uses spam to advertise, and that spam has fraudulent headers, then the U.S. company can be prosecuted. That's the true origin of spam-- not the IP address of the sending machine. This allows for a non-technical approach to combat the true originators of the messages.
Why do spammers use fraudulent headers anyway? To evade technical spam-blocking techniques (RBLs, whitelists, etc.). As the spammers start to reduce their use of such methods, the technical techniques used by many ISPs and end users will be more effective. No silver bullet, to be sure, but every little bit helps.
The biggest problem is ATT will have to administrate this. If a (legitimate) domain switches IP addresses on their outgoing SMTP server (it happens), ATT will have to deal with it by setting up some kind of structure to accomodate such changes.
Forcing domains to declare from what SMTP host legitimate mail will come from is actualy a good idea. It has been proposed before, in the form of SPF:Sender and RMX.
Either would do the job (technical quibbles aside), and would accomodate the end goal ATT is trying to achieve.
I certainly agree that egress blocking will not solve the spam problem-- there is no "silver bullet". It will also take many ISPs to play along, which can take time.
The advantages for a single ISP are that it will stop virus/trojan generated messages (which consists of both spam and more viruses), lower the number of complaints, and (if the reported numbers are correct) significantly lower their bandwidth.
The advantages for spam fighters (define as you please) is that spam will come from fewer and fewer IP blocks, and efforts can be concentrated on them.
The advantage for end users, eventualy, is less spam as the previous two points start to become more widespread.
This is exactly what needs to be done! The only people negatively affected by this are people running mail servers on their consumer level accounts. To them-- I am truly sorry. No sarcasm there, running your own server is "cool" and does allow you a somewhat higher level of control over your "domain" than relying on your ISP's server. But this spam problem is just out of hand, and let's face it-- running a server is just not "consumer level". Sorry. Pay a little more for a business level account. And "zcat NZ" is correct, your IP address is probably on a DUL anyway (or will be soon).
I hate to sound like a broken record, but maybe these ISPs need to start seriously thinking about blocking outbound port 25 traffic (except, of course, for their own mail servers).
Please rephrase "How dare you put a limit on my ability to run a mail server!!" to the more appropriate "I want to continue getting away with a business level of service on my consumer priced account". Also, please don't reply about how blocking port 25 will ruin the Internet-- that is not what I suggest.
It's time we all grew up. ISPs need to realize that there is a serious price to pay for allowing spam to proliferate. Yes, it is their fault-- from the infamous "pink contracts" of UUNet, PSI, and others, to the just plain dumb policy of allowing egress TCP port 25 traffic.
Standards for communication protocols. A variety of components from different manufacturers, all interoperating because everyone follows the standards. "Embrace and extend" is fatal-- your components won't be chosen by the end user (in this case, the car manufacturers).
This is a true driver of innovation (that word I always hear from one of our beloved software manufacturers). You know your product will compete on its merits, because any manufacturer (or, I suppose, car owner/tinkerer) can truly plug it in to almost any car on the planet.
Actualy, Dreamweaver requires that use use FTP, and has posted suggestions for tunneling FTP through SSH (e.g. PuTTY). To set this up on the server is not exactly easy, particularly with a firewall on the server (due to the ranges of ports that need to be opened).
While this can be done, to do so is an error prone task at best, and can easily leave a system more vulnerable. I don't see how, with free libraries available, Macromedia can't just do the responsible thing and bundle SFTP into their otherwise excellent products.
Slashdot Mirror
No, that is not what I meant. I meant and end user submits their mail to an SMTP server that they are authorized to use. This could be their ISP's server, or it could be their company's located in a faraway land. The point is that the act of initial mail submission needs to be on a different port than 25 (I suggest 465 for SMTP+SSL+AUTH). Now even if your ISP is blocking port 25, your IMS can still go through, since the SMTP server you want (and presumably are authorized) to use accepts IMS on port 465.
SMTP was not designed as a peer to peer protocol. It was clearly designed to have mail transport handled by duly assigned SMTP servers, as indicated by MX records in a domain's DNS zone.
Eventualy, mail being recieved from remote hosts (that is different from initial mail submission, which ought to require an AUTH step) arrives on port 25. So if there is a trojaned host somewhere accepting mail on port 25356, so be it. It will need to eventualy send that mail out to somebody's SMTP server on port 25. If the ISP is blocking such traffic, then the spam/virus/trojan is blocked.
Therefore, I don't propose anything other than blocking egress port 25 traffic.
I don't see this as a degenerating spiral at all. Port 25 is being constantly abused for purposes other than what it was designed for (SMTP transfers between properly configured MTAs). There are a few other ports that have been abused as well (135), but they are very much the exception and not the rule. People who run and manage ISPs are advocating these sorts of measures because the abuses are getting overwhelming.
That's exactly the problem. Mail is not supposed to be transmitted from any IP host to any IP host. The way it is supposed to work is:
- End user submits mail to their SMTP server
- SMTP server queues the mail, looks up the MX hosts of the recipient, and attempts delivery (this step may take time, due to internet congestion, etc.)
- Recipient's SMTP server receives the message (possibly from a backup MX host)
- SMTP server delivers the message to recipient's POP/IMAP/etc. server (maybe Exchange)
- Recipient accesses message using their e-mail client (Pine, Outlook, Eudora, Mozilla, etc.)
In particular, the message is not sent directly from the sender to the recipient! That won't work-- what if the recipient's workstation is off? What if the recipient uses several different computers (devices) to access their mail? SMTP was reasonably well thought out, the only problems realy are that IMS and mail transport were originaly designated to use the same port, and there was no encryption or authentication built in. Now with SMTP+SSL+AUTH, and IMS on an alternate port, it is pretty robust.Correct, that port is a different port, used for IMS. When you add SSL (and I strongly recommend AUTH as well), the proper port is 465 (SMTPS). Or not-- nothing wrong with 587, the theory still holds. Or use port 26, as the previous post suggested.
Initial mail submission is different than mail transport!
This is getting ridiculous. All of these worms/viruses of late have their own SMTP engine built in, and connect directly to external SMTP servers to spread their payload. ISP's (and businesses that provide access to internal workstations) need to block access to external SMTP servers! In particular, block egress port 25 from the network.
So you will ask, "But then how will I use my company's or other SMTP servers from home?" Easy, the port used for initial mail submission (IMS) should be set to a different port altogether. IMS and mail transport are different activities and should be treated as such. Use SMTP+AUTH+SSL, run it on port 465, and everybody is happy (except spammers and virus authors).
"But I want to run my own server on my dial-up or other consumer level account!" Contact your ISP and see if you can get a static IP address. SMTP servers should be on static IPs, that way bounces and other system messages can be routed properly. Check the AUP of your ISP, you might be prohibited from running a server on your account (find another ISP, or use the tip above to use a different SMTP server).
To do otherwise is to continue to be part of the problem, not part of the solution.
Starting with FreeBSD 4.x, ifconfig with no arguments simply lists all interfaces the kernel has found, and their configuration details.
(the actual output has tabs to make the formatting a little prettier)I could not help but notice that Google, Yahoo, and Slashdot are omitted from their "top 1000" list. Yet rumors persist that these three web sites get a fair amount of traffic.
Searched from MSN (listed by number of results):
- Results 1-15 of about 1136552 containing "freebsd"
- Results 1-15 of about 341343 containing "openbsd"
- Results 1-15 of about 200091 containing "ipsec"
- Results 1-15 of about 96796 containing "postgres"
- Results 1-15 of about 9641 containing "plan9"
- Results 1-15 of about 408 containing "OS/2"
- Results 1-15 of about 365 containing "linux"
- Results 1-15 of about 113 containing "apache"
- Results 1-15 of about 76 containing "php"
- Results 1-15 of about 40 containing "mysql"
Clearly, those platforms that MS does not like are treated differently than less popular (and less threatening?) technologies. Or maybe Plan9 is finaly picking up steam.No need to use your ISP's servers at all. Have the admin of the mail server you wish to use configure the server to use SMTP+AUTH on a different port. Even better, use SMTP+AUTH+SSL. No blocking, the chain of responsibility is intact, everybody is happy.
There is something wrong with using port 25 for initial mail submission. Submitting a mail message by an end user is a different activity then two SMTP servers transmitting mail to each other.
Initial mail submission is a potential security violation, and certain restraints on relaying mail are important. Here is where SSL and SMTP+AUTH make sense. The user submits the mail, and then can forget about it-- the SMTP server will now handle the rest, including queuing the message in case the remote MX host is down, etc.
Mail transport is between two SMTP servers. MX hosts are looked up, and each tried in a specified order until the message is delivered to an appropriate recieving SMTP server. In some cases, the message is queued for hours or days.
These are different activities, and ought to be handled as such. That is why the alternate ports are used for initial mail submission. While it is true that STARTTLS will work over port 25, it is a disservice to the users of that mail server to configure it that way. What about remote users who's ISP is (responsibly) blocking port 25? Or, as another poster pointed out, silently relaying all outgoing port 25 traffic to their own server? The alternate ports solve this problem quite well.
I have many clients on DSL lines, too. They have arrainged with their ISP for a static IP address, and the ISP pretty much lets them do whatever they want to. Any malicious activity, and they know where to find them.
This is certainly good news. Now their customers who are infected will figure things out pretty quickly!
Of course, this would have been easier if they just blocked egress port 25 traffic (which would not include their own SMTP server, of course!). Imagine all ISPs blocking egress port 25 traffic for their DHCP clients (e.g. most cable modem, dial-up, and DSL), and shutting off their corporate clients who spew spam! That would effectively eliminate spam, since IP addresses left still sending spam (directly or due to a trojan/virus) would quickly end up on DNSBLs.
It is irresponsible for ISPs to operate otherwise. Simple steps to be a good netizen:
- Don't use port 25 for initial mail submission. The fact that this port is used for both mail transport (between systems) and initial mail submission (which is really a different activity if you think about it) is a mistake. Use port 587 with SMTP+AUTH, or port 465 with SMTP+AUTH+SSL
- Implement one of the reverse lookups for incoming SMTP traffic (RMX or SPF:Sender) when one of the competing proposals become a standard (and your software catches up)
- Block egress port 25 traffic from your network
These apply to any businesses that supplies IP connectivity to any other computers (offices, schools, WISPs, in addition to standard ISPs). To not do so is to be a part of the problem.While it is true that some DNSBLs block entire netblocks, those lists are used by the fewest people. There are a great many DNSBLs one can use to block mail, some are maintained better than others and most have different criteria for inclusion and removal. Use the ones that match your philosophical opinion of spam, don't use the ones that you feel are too extreme.
It's all about freedom of choice!
It looks like this is a bit more specific than the original post would lead one to believe. It does not cover installing software remotely. This patent is more about saving a user's settings remotely, then transferring them to a new computer. Looks like it is a way to facilitate the use of a remote IT staff. It does not look like it covers downloading software install packs, nor does it seem to cover software updates. But hey, IANAL :)
That's not the way the particular spam you mention works, correct. But the online pharmacies, stock pump-n-dump schemes, porn, 'work-at-home' and other spam messages generaly have a U.S. component to them that gets the cash eventualy.
If this bill could just eliminate spam for anti-spam software I would consider it a success.
Yes, the spam mostly comes from IP addresses outside the U.S. However, it is almost always advertising something sold by an entity in the U.S.
This bill, if passed, can have an effect. If a company in the U.S. uses spam to advertise, and that spam has fraudulent headers, then the U.S. company can be prosecuted. That's the true origin of spam-- not the IP address of the sending machine. This allows for a non-technical approach to combat the true originators of the messages.
Why do spammers use fraudulent headers anyway? To evade technical spam-blocking techniques (RBLs, whitelists, etc.). As the spammers start to reduce their use of such methods, the technical techniques used by many ISPs and end users will be more effective. No silver bullet, to be sure, but every little bit helps.
The biggest problem is ATT will have to administrate this. If a (legitimate) domain switches IP addresses on their outgoing SMTP server (it happens), ATT will have to deal with it by setting up some kind of structure to accomodate such changes.
Forcing domains to declare from what SMTP host legitimate mail will come from is actualy a good idea. It has been proposed before, in the form of SPF:Sender and RMX. Either would do the job (technical quibbles aside), and would accomodate the end goal ATT is trying to achieve.
The link provided requires a user name / password.
I certainly agree that egress blocking will not solve the spam problem-- there is no "silver bullet". It will also take many ISPs to play along, which can take time.
The advantages for a single ISP are that it will stop virus/trojan generated messages (which consists of both spam and more viruses), lower the number of complaints, and (if the reported numbers are correct) significantly lower their bandwidth.
The advantages for spam fighters (define as you please) is that spam will come from fewer and fewer IP blocks, and efforts can be concentrated on them.
The advantage for end users, eventualy, is less spam as the previous two points start to become more widespread.
Your 'solution' does little but piss off a group.
My solution (not just mine, if you read the rest of the comments) solves the problem of trojaned windows machines, as well as Outlook viruses, etc.
OK, I'll bite:
Link 1, Link 2, Link 3
Yes!!
This is exactly what needs to be done! The only people negatively affected by this are people running mail servers on their consumer level accounts. To them-- I am truly sorry. No sarcasm there, running your own server is "cool" and does allow you a somewhat higher level of control over your "domain" than relying on your ISP's server. But this spam problem is just out of hand, and let's face it-- running a server is just not "consumer level". Sorry. Pay a little more for a business level account. And "zcat NZ" is correct, your IP address is probably on a DUL anyway (or will be soon).
I hate to sound like a broken record, but maybe these ISPs need to start seriously thinking about blocking outbound port 25 traffic (except, of course, for their own mail servers).
Please rephrase "How dare you put a limit on my ability to run a mail server!!" to the more appropriate "I want to continue getting away with a business level of service on my consumer priced account". Also, please don't reply about how blocking port 25 will ruin the Internet-- that is not what I suggest.
It's time we all grew up. ISPs need to realize that there is a serious price to pay for allowing spam to proliferate. Yes, it is their fault-- from the infamous "pink contracts" of UUNet, PSI, and others, to the just plain dumb policy of allowing egress TCP port 25 traffic.
Standards for communication protocols. A variety of components from different manufacturers, all interoperating because everyone follows the standards. "Embrace and extend" is fatal-- your components won't be chosen by the end user (in this case, the car manufacturers).
This is a true driver of innovation (that word I always hear from one of our beloved software manufacturers). You know your product will compete on its merits, because any manufacturer (or, I suppose, car owner/tinkerer) can truly plug it in to almost any car on the planet.
Actualy, Dreamweaver requires that use use FTP, and has posted suggestions for tunneling FTP through SSH (e.g. PuTTY). To set this up on the server is not exactly easy, particularly with a firewall on the server (due to the ranges of ports that need to be opened).
While this can be done, to do so is an error prone task at best, and can easily leave a system more vulnerable. I don't see how, with free libraries available, Macromedia can't just do the responsible thing and bundle SFTP into their otherwise excellent products.