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
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.