Solution
The attack prevention is based on identifying and authenticating the subscriber. Currently, secure Web sites use the double opt-in procedure by sending an email to the subscriber asking him/her to send back a reply as a confirmation. However, this can easily be used for the attack as a million e-mails asking you to confirm your subscription is more than enough to bring down your server.
Our solution follows a very simple strategy:
- The user enters the necessary information in the form (including the e-mail address that will be used for the subscription --- let's call it EMAIL1)
- After clicking the "Subscribe" button, a new page is shown to the user with a mailto link.
- The user clicks on the mailto link and an automatic e-mail is sent back to the Web page sponsor.
- The web page sponsor can verify from where the e-mail has been sent. Even if the "From" of the e-mail can be spoofed, the IP address of its legitimate ISP 's SMTP server cannot.
- EMAIL1 is matched against the sender's SMTP server's IP address. If the match is positive, then the user is subscribed; otherwise, the subscription is rejected.
Example:
Say you want to subscribe to this secure Web site. You fill the form and also include your e-mail address where you want to receive the newsletter: Gasper@somemail.com. Then, as you click the subscribe button, a new Web page comes up asking you to click on the mailto link for confirmation. The mailto link will automatically send an e-mail to the secure Web site. The email headers will look like:
Date: Tue, 26 Oct 2004 16:16:59 -0500
From: Gasper <Gasper@somemail.com>
To: secureWebSite@mail.com
Subject: subscription
Received: from [119.69.284.228] (authenticated bits=0)by mail.somemail.com; Tue, 26 Oct 2004 16:16:59 -0500 (EST)
The secure Web site will check where the e-mail came from (the IP address of the ISP's SMTP server). In this example, the server is mail.somemail.com. At this point it is easy to compare the server domain (somemail.com) to the domain of the first email (Gasper@somemail.com). We see that somemail.com (in the server) equals somemail.com (in the e-mail), so we deduce that it is the same person.
Caveats:
There are some caveats to this strategy. Let's say John wants to play a trick on Mary. John subscribes Mary (mary@somemail.com), then clicks on the mailto link for confirmation. The hic is that John's e-mail is also in somemail.com (john@somemail.com). In this case, the secure web site will consider it as a valid subscription and will accept the subscription; however, the attack becomes traceable.
Another problem is that some servers do not have the same domain as the e-mail account. So John subscribes himself this time with his email john@somemail.com. The server of somemail.com has a different name (instead of mail.somemail.com as in the previous example, it is called mail.intheworld.com). In this case, the subscription will be rejected even if the user is real.