Spam is a problem that is beginning to have a serious impact on the continued success of the GetSite GetSite^SM service and our customers. Due to the overwhelming growth of the GetSite^SM service there has been what unfortunately amounts to a literal explosion of Spam originating from GetSite's Wholesale Dialup ports. With the hundreds of ISP's utilizing the GetSite^SM service to expand their national footprint, the likelihood of a spammer signing up with an ISP using the GetSite^SM service is rapidly increasing.

Background

The way spam is typically sent has continually changed, as new ways to combat and block it have been developed. The current trend in sending spam employs software that runs over a dialup connection and connects directly to the mail port of the target. This is the hardest to block, because it doesn't pass through any "mail relay" servers, on which anti-spam filters could be employed. The target has difficulty in stopping the attack without also blocking other legitimate mail from coming through. Once a spammer is identified, the account can be quickly identified and terminated, but due to the success of the internet and the ISP market, many accounts can be obtained on a trial basis for little to no money, accounts can be activated over the phone with falsified information, and other tricks to gain a "throw-away" account. ISP's can combat the proliferation of spam accounts, but due to market pressures, most do not scrutinize each account to ensure that it is not going to be used to spam. The further a company is from dealing with the individual end-users, the harder it becomes to scrutinize new accounts. It is not realistic to expect this of every ISP, and even when such monitoring is done, it cannot completely prevent this type of spam from being sent. Careful monitoring merely stops spammers from being able to spam with free accounts. Some would argue that once spammers are hit in the wallet, they will mend their ways and move on to something else. That is not likely to occur, and we already know that type of checking is not being done.

This is the issue facing GetSite today. GetSite can no longer afford to be reactive to the spam issue. There are too many spammers, using too many "throw-away" accounts to continue to attempt to combat the problem in this way. Therefore, we must implement a proactive solution that stops all accounts (whether legitimately gained or otherwise) from being abused in this manner. If the spammers are unable to use any GetSite^SM ISPs to spam, the problem will be completely and finally resolved.

The Problem Defined

Mail uses TCP port 25 for sending and receiving mail between servers. What spam software does, is connect directly to TCP port 25 on the mail servers being targeted. Because it connects directly in this fashion it is extremely difficult for the target server to block the incoming spam. What needs to be done to solve the problem is to keep the dialup user from being able to connect directly to TCP port 25 on their target systems.

The Solution

Blocking port 25 is extremely easy to do, but one problem with blocking port 25 is that once done, legitimate users can no longer send email, as they cannot connect back to their ISP's mail server. Maintaining a single filter to allow access back to each GetSite^SM customers mail servers is a very large undertaking. Figure that each ISP has a minimum of two mail servers, with hundreds of ISP's currently, that is over 1,000 lines in the access list. Add in the fact the some ISP's have more than two mail servers, and that some GetSite^SM customers are in turn reselling the GetSite^SM service to yet more ISP's, and you suddenly have an extremely long and complex filter, a filter that has to be updated every time an ISP is added to the service, leaves the service, or has to change its server's IP's. This is not a very difficult option, but so far the only complete one, that least impacts you the GetSite Client and your users.

Another solution is to assign a separate filter to each individual port through radius at the time of authentication. This we already do, to a certain extent, as part of our Filtered Access service. What we will do is apply a filter to all users dialing into the GetSite^SM service. This filter will vary depending on the customer the end-user is signed up with.

Filtering will be done on a 'per-realm' basis. That is, all customers of a given 'realm' will be directed through the same filter. For those customers who utilize proxy radius, you will already have a 'realm' assigned. Those customers using the Account Manager will need to have a realm created if you wish to utilize a filter other than the standard one that will be applied to all Account Manager accounts.

As large of an undertaking as it is, the solution most likely to succeed, and the one which we are intending to implement, is to force all port 25 traffic through "relay" servers under the direct control of GetSite or it's direct customers. The GetSite servers will have spam-filtering software installed so that legitimate mail is passed through, and spam mail is discarded. This also means that legitimate users can send mail, but spammers will be unable to connect direct to the targets.

To all GetSite^SM customers we are proposing the following options:

• Use solely the GetSite provided relay servers for sending mail. The filter applied will be a general one that all customers can use. The filter will restrict only TCP port 25 outbound traffic. The filter will affect nothing else.
• Customers using the Account Manager will have the option of having a specific set of IP's allocated to the "relay servers" in order to maintain their own unique identity.
• Use other relay servers in combination with the GetSite-provided servers. Each ISP that wishes to do this would need to supply GetSite with a list of the IP ranges of mail servers that they want their end-users to be restricted to for TCP port 25 outbound traffic.

Our timeframe for implementing this is as follows:

• Customers with existing realms will have until 9/15/1999 to supply a list of allowed addresses to GetSite for inclusion/design of a custom filter for each realm. Once the list of allowed addresses is supplied to GetSite, the filter will be deployed in approximately one (1) business day.
• Customers using the Account Manager who wish to have their own unique IP's assigned to the "relay servers" will need to return that information to GetSite by 9/15/1999. Once received by GetSite the IPs will be allocated and configured in approximately one (1) business day.
• Customers using the Account Manager will have until 9/30/1999 to convert their customers over to using the GetSite "relay servers" before the General Filter is applied to them.

GetSite plans to implement this solution as quickly as possible, while causing as little impact on the end-users as possible. We want to work with all of our customers on this to make this process as transparent to the end-users as can be. We welcome any feedback that you may have regarding this proposed solution. Please contact your Customer Service Representitive with any questions or comments.