On Thu, 27 Jun 2002, Robert Strickler wrote: > How does everyone feel about building the logic to create and maintain a > database of unsubscribe/removes that actually remove an address.
This sounds like a worthwhile endeavor. A bit of a digression: On Thu, 27 Jun 2002, Derrick 'dman' Hudson wrote: > Certainly there is value in getting off the lists ... I don't think > "unsubscribing" will truly work. If the spammer cared about your > (un)subscription preferences, he wouldn't have spammed you in the > first place. For most "full-fledged" spammers, you're probably right. However, there is a grey area -- cf. my message from some days ago about well-meaning marketers who don't recognize the downside of using "appending" to add to their subscriber lists. Nearly all of those really do want to leave you alone if you think they're spamming you, but the recipients are often so cynical/paranoid about unsubscribe procedures that they won't even try. So such a list would probably end up being a catalog of "white hat" and "grey hat" organizations: those who aren't (deliberately) spamming, but who send mail that at least sometimes "looks like" spam. > The best way to refuse membership in the spam lists is with sa-exim : > http://marc.merlins.org/linux/exim/sa.html With sa-exim you don't even > accept the message in the first place. As a result, your live address > looks like it is dead to the sending SMTP server. I've been using > sa-exim for quite a while now and am very happy with it. Using SA to reject messages at the MTA level can, I think, cause some confusion. Suppose you sign up for a retailer's newsletter. [*] The first newsletter arrives, scores less than your threshold, and gets to you just fine; your address appears good, but the next newsletter includes some sort of promotional offer that pushes it over the threshold. Now the sender gets a bounce. What's he supposed to do? Most mailing list software won't delete an address because of a single bounce, so he goes ahead and sends the next newsletter. This one is "less spammy" and gets through, and the cycle continues. You're giving the sender inconsistent information. [*] OK, maybe you never do this, but consider an end user at an ISP where that ISP has decided to use SA for MTA-level blocking. The end user is likely to be confused when newsletters are delivered sporadically or when some other mail he expected to get never appears. Besides, the spammers who don't care about your subscription preferences aren't all that likely to care whether your email address appears "live" either. Back to Robert Strickler again: > We would need to validate removals with non-live addresses and share the > database of "legitimate" removals. The sharing should be able to use the > same mechanism as the rule sharing that has been discussed on the list. A number of things to consider: - The validation scheme has to be clever enough to prevent spoofing. (A "non-live" address might get dropped just because it doesn't appear to be live, not because an unsubscribe had any real effect.) - A listed entity has to have some sort of stability; e.g., the domain name has to stay live, or some such test. - It ought to be difficult (or somehow strongly discouraged) to use the list for blocking; it's supposed to be list of (relatively) good guys. Hmm. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Bringing you mounds of caffeinated joy. http://thinkgeek.com/sf _______________________________________________ Spamassassin-talk mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/spamassassin-talk
