Slashdot Mirror


How to Kill Spam Without the State

WaxParadigm writes "The Colorado Freedom Report, an online libertarian publication in Colorado, has an article today about How to Kill Spam Without the State. Will our heavy-handed attempts to stop spam through legislation have the outcome we desire?" The article advocates putting the burden on the end user, saying "We must also take personal responsibility to kill spam. We can't pretend the politicians will do it for us. Their incentive is to develop a cute re-election flyer, not solve the problem. If you're still tempted by the political approach, ask yourself one simple question: who is more technologically savvy, your average spammer or your average politician? There are steps each of us can take to kill spam, and to help foster a culture that encourages spam killing." While this forgets the onus of spam on the ISP and telco companies, it should well be part of a multi-tiered plan against spam.

3 of 517 comments (clear)

  1. I think, the solution... by SharpFang · · Score: 5, Funny


    1) Set up a "trade site" anonymously. Very anonymously.
    2) Get your hands on a spammer's mailing lists.
    3) Send out several millons of spam with "new better penis enlargement" or some other viagra.
    4) Receive all the offers. Even don't bill them, just send out the product. TRICKY PART: Don't send any viagra or other penis enlargers, send out cyanide or some other really lethal poison.
    5) Run, wipe all your tracks before your mail reaches its destinations. Leave the "spamming server" with a note on the harddrive for the police to find: "These idiots deserved to die. As long as anyone answers to spam, such 'accidents' will happen. This is not our last action". Take care that it gets to the news.

    Fear is a powerful weapon.

    --
    45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
  2. Doped up big penises with lower interest rates by snatchitup · · Score: 4, Funny

    I for one feel comforted by the fact that if, God forbid, the day comes that I can't get it up for my wife, and I feel so bad and depressed, and my mortgage interest rates are so high.....

    I feel comforted that everyday, there is veritable kornikovia(sic) of options.

  3. You Might Be An Anti-Spam Kook If ... by dwsauder · · Score: 2, Funny

    You Might Be An Anti-Spam Kook If...

    Source: Posted to IETF mailing list by Vernon Schryver.

    • you have discovered the Ultimate Final Perfect Solution To The Spam Problem (UFPSTTSP).
    • you are the first to think of the UFPSTTSP.
    • you were motivated to find the UFPSTTSP because you know it is impossible to filter more than 99% of spam with fewer than 0.1% false positives by any of several currently available mechanisms.
    • despite being the inventor of the UFPSTTSP, you are unfamiliar with "false positive," "false negative," "UBE," "tarpit," "teergrube," "Brightmail," "Postini," "SpamAssassin," "DNS blacklist," "HELO," "RBL," or "mail envelope."
    • you plan to make money by licensing the idea of the UFPSTTSP.
    • you are deeply offended when people do not agree that you have found the UFPSTTSP.
    • you cannot name several potentially fatal flaws in the UFPSTTSP.

    • you think all you need to do to get the UFPSTTSP implemented and deployed is to publish an RFC.
    • you don't recognize the difference between deploying and implemeting the UFPSTTSP.
    • you plan to publish an RFC mandating the UFPSTTSP but have no idea that RFC 2223 or RFC 2026 exist.
    • you have no idea of the relevance of "consensus" or "IESG approval" to publishing RFCs.
    • you think all RFCs have the same standing.
    • you think that spammers won't ignore, subvert, or exploit the UFPSTTSP if you publish it as an RFC.
    • the UFPSTTSP depends on spammers or mail recipients changing their behavior without any immediately gain.
    • the UFPSTTSP won't be effective until it has been deployed at more than 60% of SMTP servers and you don't think that's a problem.
    • the UFPSTTSP is trivial to implement and deploy, but you have done neither.
    • you feel your job is done after having explained the UFPSTTSP, and that "programmers" will drop everything to implement it.
    • you think that a violation of an RFC by an SMTP client or server is good and sufficient reason to reject all mail from the system's domain.
    • you think that SMTP has no authentication and have never heard of SMTP-AUTH, SMTP-TLS, S/MIME, or PGP or think they're irrelevant to the lack of authentication in SMTP.
    • you think that the fact that most SMTP servers do not authenticate the SMTP clients of strangers is a major bug in SMTP instead of a major feature and expression of a primary design goal.
    • despite discovering the UFPSTTSP, you don't know the meanings of MTA, MUA, SMTP server, or SMTP client.
    • the UFPSTTSP requires a small number of central servers for validating email, serving as "pull servers" for bulk mail, or anything else.
    • the UFPSTTSP requires that anyone wanting to send mail obtain a certificate and that such certificates would be checked by all SMTP servers.
    • you think that useful certificates of a person's identity that certifies not only that the person has that name but has no other certified names are cheap and easy.
    • you think that most Internet users would willingly pay more than $5/month to avoid spam, and don't know the per-user price point for anti-virus software or data.
    • you don't see why a certificate that binds a name to a user is useless against spam unless it also certifies that the user has no other names.
    • the UFPSTTSP involves ISPs issuing certificates to users and that the same ISPs that don't terminate the accounts of spammers or don't investigate prospective customers enough to refuse service to spammers will refuse certificates to spammers.
    • you've never heard of RFC 2554 or RFC 2487 and the UFPSTTSP has something to do with authentication.
    • the UFPSTTSP involves replacing SMTP.
    • you routinely send single "LARTS" or reports of single examples of objectionable mail to more than two dozen addressees.
    • your definition of spam differs significantly from "unsolicited bulk email".