How to put an end to Virus Infected Spam Bots

From Computer Tyme Support Wiki

(Difference between revisions)
Jump to: navigation, search
m (SMTP Isolation)
m (SMTP Isolation)
Line 23: Line 23:
== SMTP Isolation ==
== SMTP Isolation ==
-
My idea is to isolate consumers from talking directly to incoming SMTP servers. Picture this model.
+
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.
-
  Consumer -- Port 587 --> ISPs Outgoing SMTP Server port 25 -->  
+
  Consumer -- Port 587 --> ISPs Outgoing SMTP Server -- port 25 -->  
  --> rcpt ISPs Inbound Server -- Port 110 POP --> recipient
  --> rcpt ISPs Inbound Server -- Port 110 POP --> recipient
 +
 +
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.
 +
 +
== Implementing Port Blocking Policies ==

Revision as of 16:51, 19 July 2007

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.

Contents

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.

Consumer -- Port 587 --> ISPs Outgoing SMTP Server -- port 25 --> 
--> rcpt ISPs Inbound Server -- Port 110 POP --> recipient

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.

Implementing Port Blocking Policies

Personal tools