How to put an end to Virus Infected Spam Bots

From Computer Tyme Support Wiki

You do not have permission to edit this page, for the following reasons:

• The action you have requested is limited to users in the group: Users.
• This page has been locked to prevent editing.

You can view and copy the source of this page:

Many people think that there's no way to win the war against the spam bot army. I don't agree. I think that it is winable and that through policy changes but ISPs that virus infected computers can be detected and isolated. This is a war we can with without restricting good email or infringing on the freedoms of people to freely communicate. In this article I will try to outline the problem and simple changes that can lead to a solution. The more ISPs adopt these ideas the less spam and viruses we will all have to deal with. We at [[http://www.junkemailfilter.com Junk Email Filter]] have created the following guidelines to help ISPs and software developers to help defeat the spam bots. We welcome feedback and new ideas to combat spam. Junk Email Filter is an innovative front end spam filtering company with the most advanced spam filtering technology on the planet. If you have a comment or suggestion feel free to contact us at [[mailto:support@junkemailfilter.com support@junkemailfilter.com]]. <br> == Defining the Problem == One of the problems with Spam comes from the history of SMTP. Originally email was send between Unix servers over SMTP. The user created an email message from the Unix command line. That message was sent from the sending server to the receiving server where it was appending to the receivers mail file. At that time only sophisticated users had email and there was no spam. As time went on more people gained access to the Internet and instead of user logging into Unix shell accounts users had PCs and email clients. Even though servers still stored email in Unix accounts the end users never logged into a Unix shell. Instead they downloaded they email using POP/IMAP protocols which gave them email access from their personal computers. == Consumers and Experts == As the internet grew more and more common people had access to email and people started spamming these users to advertise commercial products. But the spammers evolved into scams and criminal identy theft. Not the Internet is very different with most people being consumers and the original technical people being only a small fraction of Internet users. This leads to what I will call two classifications of people which I will refer to as "consumers" and "experts". A consumer is a person who just wants to surf the web and get email without having to understand anything about how things work. These people are generally (for the purpose of this discussion) technically unsophisticated and are vulnerable to being misled or tricked into allowing theivs to install viruses on their system. == Problems with the old SMTP model in the Modern World == One of the problems with the SMTP model in the modern world is that although consumers get their email using POP/IMAP they still send email using SMTP. The problem with this is that receiving SMTP servers have no way to distinguish a connection from a real email server from a virus infected spam bot. The SMTP protocol has evolved though and there are not new alternatives that have been standardized and I believe that using the existing new standards we can isolate viruses so they can't send spam and they can't spread. The trick is to prevent consumers from talking to servers other than the putgoing SMTP server they are supposed to use. This can be accomplished by using Submission (port 587) instead of SMTP. Submission can be as simple as SMTP on an alternate port without a password but restricted to the ISPs customers, or it can be authenticated SMTP open to the world but requiring a user name and password to access. == SMTP Isolation == My idea is to isolate consumers from talking directly to incoming SMTP servers. Picture this model. ISPs have two classes of SMTP servers. One server is for receiving email from consumers to relay to the outside world [outbound server]. The other is to receive email from the outside world to deliver to the consumer's inbox [imbound server]. Email is sent from the sender to the ISPs outbound server, which relays the message to the recipient's IPSs inbound server where it is stored till the recipient pops it. ISPs Hardware: ISP --> Outbound Server --> Internet ISP <-- Inbound Server <--- Internet Email Routing Sender --> ISP --> Outbound Server --> Internet Internet --> Inbound Server --> ISP --> Recipient More Details: Consumer -- Port 587 --> ISPs Outgoing SMTP Server -- port 25 --> --> recipient ISPs Inbound Server -- Port 110 POP --> recipient Blocking Model Virus -- Port 25 --> XXXX ISP Blocked XXXX --> recipient ISPs Inbound Server In the above model the consumer would have port 25 blocked by default allowing the consumer to send email only on port 587 to outbound servers and would be blocked from talking to inbound servers. That way virus infected consumer computers couldn't talk to inbound servers at all and the spam bot can't send spam. If the ISP required password authentication on outbound email then the virus wouldn't be able to send on port 587 because the virus wouldn't know the password. * Outbound Servers have port 587 open to the world accepting authenticated only * Outbound Servers will accept connections from their customers on port 25 or 587 * Outbound Servers block port 25 connections from outside world * Inbound Servers accepts port 25 connections from the world for domains they service * Inbound Servers block connections on port 587 == Implementing Port Blocking Policies == The best way, in my opinion, to implement port blocking policies is that they DSL/Cable Modem shipped to the consumer should by default bet set up to NAT and to have vulnerable ports blocked that most consumers don't need. In order to satisfy the needs of experts however the modem device should have a menu to disable NAT and port blocking. The idea here is to protect the rights and needs of professionals while protecting consumers from predators. The expert will be able to easily reconfigure the modem for full access and is assumed to be smart enough to not be exploited, where the consumer will never notice the default restrictions to protect them. The NAT will allow the user to surf the web without the web surfing the consumer. Thus if the consumer has software vulnerabilities they will still be protected from outside connections to the consumer's PC. I believe that in today's world that NAT protection should be the default. It also will allow the consumer to connect multiple computers without additional equipment. User's Computer --> NAT --> ISP --> Internet User's Computer --> Port 25 --> ISP's Outbound SMTP User's Computer --> Port 25 -- XXXX Blocked XXXX --> Internet == Outgoing Port 25 Blocking through Router Policies == We all know it is hard to implement anything which requires change. So there needs to be some sort of interum solutions for those who don't want to make massive changes. ISPs can implement outgoing port 25 blocks in their routers so that the consumer can only talk to port 25 on the ISPs outgoing email server. This could be implemented on the fly if automated alerts indicate that the consumer's computer has been compromised. The consumer will be alerted by email and the restriction will be lifted when the virus problem is fixed. == Switching on Port 587 for Outgoing Email == One thing that ISPs can and should do is to add port 587 to accept outgoing email from their customers and to start encouraging they customers to configure their email clients to use port 587. This will start to alter the email culture to prevent consumers from talking directly to inbound servers. Inbound servers will have port 25 closed or restricted to authenticated users only. All outbound servers should support port 587 so that consumers can start to switch. Email clients like Outlook and Thunderbird should default to port 587 instead of port 25. We need to encourage the email client developers to use the submission port instead of the SMTP port. == Consumer port 25 to 587 redirecting == If ISPs started opening up port 587 then consumer port 25 requests could be transparently translated to port 587 and it will still work. If all outgoing servers were to accept authenticated consumer connections on port 587 as well as port 25 then users configured for authenticated SMTP on port 25 would be transparently connected to port 587 instead and their email will still work without making any changes. Consumer --> ISP -- Port 25 to 587 Redirect --> Outbound Server on 587 - Works! Virus -----> ISP -- Port 25 to 587 Redirect --> Inbound Server on 587 - Blocked! However, if the consumer has a virus and starts trying to spam inbound servers then that will also be redirected to port 587 and the inbound servers will have port 587 blocked our requiring authentication which the virus doesn't have. This will prevent viruses from talking to inbound servers while allowing consumers to talk to outbound servers. But the port 587 structure needs to be more widely adapted first before this is possible. == Using POP/IMAP for outgoing email == Wouldn't it be nice if the same connection that received email could be used to send email? We think so. It would cut the client setup time in half. We are proposing that the POP/IMAP protocol be enhanced to allow the sending of email over the same connection that email is received on. Sender -----> Outgoing IMAP --> ISP IMAP Server --> Outbound SMTP Server --> Internet Recipient <-- Incoming IMAP <-- ISP IMAP Server <-- Inbound SMTP Server <--- Internet The idea is that you would use your incoming authenticated connection to transfer outgoing email back to your POP/IMAP server which would hand the message to the outgoing SMTP server for regular SMTP delivery. The advantages to this system are obvious. Once incoming email is set up there's not need for an outgoing configuration. It would eliminate the problem with port blocking of outgoing emails for mobile users because it isus the same incoming connection. It would also show that they outgoing message came from a person who has access to the email account that they are claiming to be. (This would be in conjunction with the IMAP/POP server forcing the sender address to match them IMAP authentication where the loging ID is the email address.) Such a system doesn't yet exist but we are very interested in seeing it developed. == Critical Mass for Viruses == In order for the bot armies to maintain themselves they need to spread so that new computers are infected to replace the ones that have been cleaned. If viruses are isolated so they can't spread then there's no way for then to spread on their own and they become extinct. By implementing these policies we reduce the spread of viruses to the point where the spam bot armies will collapse. We know that viruses are primarily transfered through either spam or TCP/IP hacking. Spam bot isolation and spam fighting technology can stop viruses from spreading through spam. NAT technology can protect consumers from PCP/IP hacking. If we do what is suggested here then we can win this, not just reduce it - but eliminate the problem. == ISP Responsibility == Our position is that anyone who provides an internet based service should take reasonable measures to ensure that the consumers they connect to the Internet are reasonably protected from the Internet and are not a hazard to the rest of the web. We think the ISP has some responsibility to keep their users out of trouble and to keep them from causing trouble. Of course you can't eliminate all problems entirely but where technology and policy exists to minimize the problem a good ISP should implement it.

Return to How to put an end to Virus Infected Spam Bots.