Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • vs. Spam (Score:5, Insightful)

    I agree these are annoying. I won't even put ads on use.perl.org. But to compare it to spam is to say people are forced to go to your web site. They aren't. The problem with spam isn't context, true, but it is the nature of it being forced on the user. If it is YOUR web site, then you are free to put on it what you wish. Comment spam is someone else putting spam on YOUR web site, where they do NOT have the freedom to say what they wish. Email spam is someone sending spam into YOUR mailbox. Etc.

    Elai
    • Excellent point pudge.

      Sadly one thing which often seems to be missing in the discussion as to how to tackle spam the fundamental understanding of the issue at hand - Spam is an issue with consent, not content. It doesn't matter if the unsolicited email message received offers me a better deal on telephone costs or a herbal alternative to viagra - The issue at hand is consent. I may choose to receive information from my telephone provider about pricing offers and updates or indeed information about alternative therapies available for purchase from a local health store, but I certainly do not want such information thrust upon me from a hundred different sources. The important factor determining whether an email received is indeed spam is the element of consent in the communication.

      Until such time that permissive based systems become more widely accepted and deployed, much of what we do to combat spam is phyrric in nature. In the meantime, I fear that the employ of content filtering and server-based blacklists serves to only narrow the difference in content, style and source of legitimate and illegitimate mail. The result will be either greater false positives or greater false negatives depending upon the nature of the content filter employed - This of course opens another avenue of discussion, off-topic however from the original post and thus I curtail my post at this point ...

      (It should be noted that I do work for a company involved in the development of a challenge-response type system, but that all the opinions expressed in this post are wholly my own)

      • The important factor determining whether an email received is indeed spam is the element of consent in the communication.

        Yes. Unfortunately, automating this seems rather difficult. In my day job, I want to receive mail from readers and potential authors, especially if we've never written before. In my free software hacker life, I want to hear from people using my code.

        The problem is identifying these people before I know who they are.

      • Re:vs. Spam (Score:3, Insightful)

        The important factor determining whether an email received is indeed spam is the element of consent in the communication

        That's a fine mantra for personal communication, but it does not apply in business. If someone wants to send Horse Porn to our customers I don't care whether they have a subscription confirmation signed in blood or not. Some spam is about content, simply because of who owns the network.
        • Some spam is about content, simply because of who owns the network.

          I can certainly understand this position and indeed I do agree with the right of corporate entities to control for what purposes their network infrastructure is employed.

          The primary concern which I have with content filtering systems however is the sensitivity of some of these systems - Whilst some email can be determined as is distinctly unwanted based upon it's content, the definition between wanted and unwanted rapidly blurs when the se

        • Even then it's still about consent; it's about the consent of the owner of the system, not the nominal "owner" of the mailbox.

          --
          J. David works really hard, has a passion for writing good software, and knows many of the world's best Perl programmers