Slashdot Mirror
IETF to Look at Spam
m00nun1t writes "CNET has an article about the Internet Engineering Task Force (IETF) looking at what they can do about spam. According to the article, many of the proposals seems to "require changes in basic e-mail technology", which presumably means SMTP (and about time!). Maybe they are looking beyond just SMTP - anyone have any insights here?"
All the (legitmate ISP's in the world should come together and make a global blacklist of (rouge) isps. Along with distributed baylasien filtering, and reject emails with forged headers a different reply-to attribute (to stop joe jobs), should stop all most the most commited of spammers.
Linux users tend to get less spam because there are less security holes to "extract" your e-mail address, a lot of spammers deliberatley take advantage of microsofts flawed software selling "evidence erasers", "spam blockers" (ironicly), "pop up lockers", and "computer cleaners", of course these software packages are visual baisc applications which open up smtp relays on your computer.
at last I will know to where in Nigeria I should go!
/solicited/ spam as being the only way you will be able to read salon. if it's still going by then.
seriously tho. even if it is all legal-ified and I'D correctly, there will still be such things as ticking the little box to say you dont want any spam from service X,Y, and Z.
In fact, the way online revenues are going i can see recieving
it would be nice(?) to have a better system but I never forget the age old adage of no system being tamperproof. Lots of enterprising folks enjoy anonymity for non-spam purposes, so naturally some form of workaround should emerge fairly quickly.
oh lord i'm sounding like Toffler.
<B>note to self:</B> <I>post as html</I>
Why don't we have a system deliver a kind of cookie for a permanent or reply only privileged contact? That would help a lot by ensuring no known important mail would get filtered.
The technology exists, off the shelf, today.
There is a SMTP command called STARTTLS which will enable SMTP over SSL. It's defined in RFC 2487. Sendmail supports it with a compile-time option, and so do most other MTAs. It's backwards compatible with normal SMTP.
You will need a certificate, of course.
This has 2 big effects:
- encryption of email in transit between SMTP servers (a nice bonus)
- authentication of SMTP servers
Since sending spam isn't illegal in most jurisdictions, knowing WHO sent the spam (or relayed it) allows you to contact them and complain, threaten and retaliate (mailbomb, portscans, DDOS, etc.)
If you receive email from a host authenticated by versign (or whoever), you apply little filtering.
If you receive email from a host not using ssl, it goes into a queue for maximum filtering.
Much of the spam I receive today is from DSL customers who spew directly.
Downside:
- there will be additional CPU load for all the email servers
- cost of certificates
Same thing must be done in email business. All messages must have correct From field, and all must be signed with key identified by From field. All keys must be signed in a public (well known and trusted) CA. The router should relay only messages with verified signature keys.
No more anonymous email!
It is not a business of the router to watch the content of the message. But the header (let's think that the sig is the part of the header) must be checked. Specifically, the key of the sig must be verified in CA for being non revoked. Of course the revoke list can be cached on the router side for performance reasons.
Then it will be very easy to create a report gathering center (it could be a DB at the same CA), where you can send the fingerprints of bad guys. Once the key collects more than N (specified) bad reports, the key is revoked, and all messages with key won't be relayed anymore.
Of course, inside the interprise you can have "old-style" non-signed email. But in order to relay the message into outside of theintranet, it must be signed. That can be done automatically by the enterprise relay on behalf of corporate users. Even using the corporate key - remember NAT for IP?
Have this infrastructure on the place and it will often unnecessary to presecute spammers: their keys will be revoked after N bad reports.
By the way, how to send a bad report? Simple. Remember Y!Mail UI? They have a link in the message header area: "Report as a spam". Same button should be in every MUA UI: "Report the key a spammer's one". As well as another button: "Bleck messages with this key" - you still can do blocking (or any other filtering) of messages locally based on the key (ID).
Why a key is better than a return address? You must have a valid key. That's the key :)
Can you generate new keys with the same speed as you can generate your return addresses? I don't think so. And if you still can generate enough of key to keep your business profitable, then let's change your profit calculation forumal. From now on, the spammer has to pay big penalties for revoked keys.
Am I am asking too much?
Less is more !
But you would have a valid email address of the
spammer. Which means it is much easier to shut
him down or sue him or whatever you think is
appropiate.
But there already exists something similar to
the idea the problem is that it isnt any
mail client that has somehting built-in.
I would like something like this:
1. You receive email. Mail client check if
this somebody you have in your addressbook
, you sent an email to him before or you accepted
an email from him before. If so pass it through
and happy ending. Other wise go to 2.
2. Mail client returns mail with some specific
format and ask for confirmation mail. It the
other client supports it can autogenerate a
confirmation. Client would only autogenerate
response if it knew it sent email for the
requested confirmation.
3. If you receive confirmation pass the mail
through.
I am sure this would reduce spam substantially
since they would have to have a valid email address. And all this without filtering.