Slash Boxes
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.
More | Login | Reply
Loading... please wait.
  • Sender vs. Receivers (Score:5, Interesting)

    by ziggy (25) on 2003.05.14 9:02 (#20107) Journal
    The difference between C/R with mailing lists and C/R with sending email is quite different. As you point out, C/R with mailing lists works because you are opting in to receive messages, while poorly designed anti-spam C/R systems put barriers to sending messages.

    Sounds to me like we don't quite understand the problem fully. Or, rather, the current C/R anti-spam solutions are simple, obvious and totally wrong.

    To get the desired effect, a general purpose anti-spam system needs to work on the receiver's end, so sender-side C/R is broken as designed. I think that the issue C/R systems are trying to automate is whitelist management for the receiver. With that in mind, a good whitelist management tool would:

    • auto-whitelist any message where I send mail to the sender
    • understand that mailing list messages are fundementally different from individual messages
    • know that I'm tired of getting jokes that have been forwarded 14 times from my dad, but I still want to get email from him
    • filter out all mail from blacklisted addresses
    Add all that up, and any whitelist management tool is going to let spam through, but it can reduce the amount of irritating and useless (possibly non-spam) email I receive.

    I think the answer here is to quarantine messages from unknown senders. If I get more than, say, 5 messages from someone without responding to a single one (or automagically adding the sender to my whitelist), then all future messages from that sender should go into a "gray" folder, because chances are pretty good I don't want to read this message. That should accomplish the desired goal: automate maintenance of whitelists, blacklists and greylists.

    • I completely agree that C/R systems should treat mailing lists differently than regular email. Fortunately, almost all mailing lists set the header "to:" field to the name of the mailing list. A C/R system should not challenge a message if the header "to:" is not to the user of the C/R system. It should put these messages into a special bin and give the user an easy way to say that this "to" is a mailing list (and the messages should be allowed to pass through). This is what does (I am the