Spam: Leave it to the sender

TalkBack 30 of 98:

Next »

« Previous

• Thread View
• Flat View

Partly right, but for a different reason

If a spammer sends a million copies of the same message out, it could theoretically result in a million copies of the message on various servers throughout the world. That's a lot of space. And with an overall spam epidemic, it does get noticed.

If you switch to a system where it stays on the sender's server, then there need be only a single copy there. It might have to have a pointer back to a list of email addresses, but nobody discussed the specifics of the architecture yet. If servers can store mailing lists, then a single pointer to that list would suffice. The next spam sent out would take up only the space of a single email, even if it's going to a million people, if it uses the same mailing list. So the space savings can be phenomenal. It should not clutter the server of the sender's ISP.

If an ISP has one spammer sending out a million emails, and a million customers receiving a single spam from somebody else, that's 999,999 emails less on the server, and possibly (or not) a copy of the mailing list. So if there is one spam received for each one sent, there is a tremendous savings. Even if 99% of it is deleted by spam detection software, there's still a big savings.

Presumably, the recipient's email client can receive the spam (or any email) by using the message id header. The email address of the recipient should not even be needed in theory for this transmission. It is needed for housekeeping. If I want to spoof the message id to get your mail, I could spoof your email address too. So knowing the message ID should be sufficient. In practice, the server would want to know when all the recipients got a piece of mail. Assuming it's not spam, it should be kept on the server until it is retrieved by all recipients. In all likelihood, there will be an expiration anyway, or servers will get cluttered any time you send something out to an address that no longer exists. Many ISPs no longer inform senders when something bounces or is undeliverable because it is filtered or blocked.

A side issue is that of security, since currently I cannot get a copy of your email simply because I have some of its header information. Granted, the content of the message ID header can be almost impossible to guess if done properly, but there are no hard and fast rules about what it should contain, only that it be unique.

So how could this make ISP costs go up? On average, the space savings will dwarf any additional space needed. But those folks with their own SMTP server who do not leave their computers on 24 hours a day will have to look for a new solution. They may have to pay for it.

For those folks who use an SMTP server that is not associated with their ISP, some costs could go up. If I use a service that assigns me email addresses, but forwards all email to my inbox (stored on my ISP's server, not that service's server) and if that server also gives me SMTP (resulting in storage on the recipient's system) then there is no storage on that service's server aside from transient data. That type of service could end up going up in price, and would need significantly more space.

Then again, we are talking about a new protocol. It won't be SMTP. It might be CMTP or something else. If I'm currently using my own SMTP server because my ISP's server is not reliable or results in email delays, I might have to stop doing that and live with the problems. Or I might have to pay somebody with a more reliable server.

If ISP's continue to regulate what they allow to be sent out, people might still need an external server to replace SMTP. Currently, some ISPs block access to the well known ports used by SMTP servers outside of their system to keep spam from originating on their systems. They also often limit the amount of email being sent by a single user to prevent spam. Users with a legitimate need for this have other solutions, and the cost of some of them may go up.

Alternatively, ISPs would have to buy into the idea of allowing senders to send whatever they want, on the theory that they can cut the user off if the user spams. But that's how things were a decade ago. If it's still easy to sign up for AOL, send out spam, and let the account die, then AOL may not care for this scheme.

On the other hand, they may be able to set their server so that if it receives more than a few complaints about a particular message ID, then it can delete it from the server or mark it as spam. If the protocol has a way to distinguish mail that was expired from mail that was recalled and mail that was marked as spam, then when the user's client fetches headers, it can transparently ignore anything that was marked as spam when it later goes to get the mail itself.
This would allow ISPs to curtail the problem to a larger extent than they do now, plus they may have a practical legal remedy if they can easily trace origins.

If this does cut down on the amount of spam on ISP's servers, will it ultimately affect the amount of spam in a user's inbox? That's less clear. If the current scheme has my email client fetch the messages off my ISP's server by using POP3 or IMAP, then those messages (may)leave my ISP's server and go into my inbox. With the new scheme, I would download the headers only, but my email client would end up fetching the bodies of the email anyway. So the bottom line is that I might see the same thing. It would probably go down if spam reporting were built into it. If I still receive it but could tell the sender's system that it's spam, that will obviate the problem for somebody else -- unless the sender is spammer friendly. This will help for big ISP's, but not for all cases. On the other hand, if the recipient's host can receive these same spam reports by message ID, then they can blacklist any that exceed a certain threshold. If 20,000 users get the email and 100 report it, then the rest might never see it. There will always be cases where somebody signs up for a mailing list by mistake and it's not really spam, so companies would have to be careful not to set a threshold too low. But spammers could get around this by limiting the number of recipients of any message on any one ISP, or stick with sending a million individual copies. Then we are no worse off than before, but no better off either, at least in terms of space, but we would be better off in our ability to trace things.

Ultimately, it could raise the cost for some users, but ideally, the system could adapt to accommodate these users too.

The logical step here would be to do things the old fashioned way: Write an RFC. Set up a usenet group called comp.mail.newprotocolname after announcing it properly. Then allow free discussion among email developers in a non-proprietary way. They can discuss the RFC and it can be revised until something works.

That method worked with the original protocols, and it worked well with MIME too. It's a good way to shake out the bugs. It's too bad we moved away from the true strength of the Internet. These things were developed openly and publicly, were not designed by corporations, and it was up to the users and the market to decide what protocols should be used.

Then anybody can write email clients that support this standard, and anybody can write servers. Any company or users can download the software for free, and any company that already has an email client or server can decide to integrate this into it if it wants to. The driving force in the past for adding MIME support and the like was that users started using it and demanded that their software support it. It's too bad we let these things slip into the hands of corporate America.

Posted by: wresnick   Posted on: 10/11/04 You are currently: a Guest | Members login | Terms of Use

Alert moderator to an offensive message

Subscribe to this discussion via Email or RSS

SponsoredWhite Papers, Webcasts, and Downloads

• The True Costs of Virtual Server Solutions VMware In an economic environment that is repeatedly heralding the message "do ... Download Now
• Addressing Compliance Requirements for Privacy, Data Retention, and e-Discovery Trend Micro Protecting individual and financial data, retaining data, and meeting ... Download Now
• Why Isn't Server Virtualization Saving Us More? A Few Small Changes May Dramatically Increase Your Efficiency VMware Companies have rapidly adopted server virtualization over the past few ... Download Now