On Wed February 25 2004 05:50, gnulinux@xxxxxxxxxxx wrote: > i'm making this request because i need a way to > positively id the messages from this list. Look in the normally-hidden headers. Most lists have something unique there. Usually it's something like a List-ID or X-Been-There line. In this case: > Sender: owner-ietf@xxxxxxxx If your MUA doesn't allow filtering on any header line you choose (including ones that aren't usually there), I seriously suggest you look into getting a new MUA. Okay, so it can be forged much more easily than a digsig. Big deal. I don't think any spammer is going to bother emailing us directly and forging that header. > i'm > spending way too much of my time culling spam from > my real email even though i'm employing the latest > spam filtering tools. Having the latest tools means nothing, unless they are used right. Are you keeping your spam definitions up to date, by either subscribing to someone else's updates, or constantly building and refining your own database (such as with Bayesian filters)? Are you applying whitelists, AND heuristics? Are you also very carefully applying blacklists? Are you observing very carefully, and tweaking, just how "spammy" your heuristics have to label an email before you dump it? Are you holding the borderline cases for review? > mailing lists could use the same recipe, no > messages would be handed over to the listserv > software unless it was signed by a whitelisted > signature. Requiring digsigs on a list would help cut down on spammers forging list members' addies to spam "only members can post" lists. Also, this is one of the few lists where I'd think most people would be clueful enough to do it. However, would it be worth the bother? Unless there's some poor sod already spending tons of his own time filtering out such spam already, I'd say no. (If there is, THANK YOU! Been there, done that, ripped up the T-shirt in frustration. You're doing a great job.) I can't recall when I've last seen a spam here. > again, this won't stop machines from > being compromised but as soon as a machine is > compromised that entity will be *immediately* > notified by their peers. in the case of a mailing > list *many* people will suddenly know who's > compromised and the list can even have a mechanism > that allows a whitelisted key to be removed once > it becomes compromised. Eh? Why would compromise necessarily change the keys? How will they be notified? Can you guarantee that the compromise won't include blocking such notifications? What's the mechanism you envision for all this? Lay out a rough roadmap, and maybe we can work it up into a draft, and then have it accepted as an RFC. Here's an alternate angle for you to chew on. Try coming up with some sort of mechanism that could easily be built into all MUAs, MTAs, mailing list managers, anti-spam "solutions", and all other programs involved, such that a user can take some simple action to sign up for an email list, and have all email from that list automagically added to his whitelist, at each step of the chain, AND the list owner can verify irrefutably that Joe Luser (or at least someone at that email address) asked to be on the list, AND in a way that would be at least difficult, if not impossible, for someone to accidentally trigger by such simple actions as "previewing" an HTML email or viewing a web page. Never mind whether the list ID can be forged by spammers, whether the list requires digsigs on submissions, or other such irrelevant details; I'm only interested in automating the verified signup and whitelisting process. (Tho if you can automate that enough that Joe Luser groks it, that would be great!) That's an idea I came up with a while back and haven't had the time to put serious work into. > apologies > to the folks whose comments i'm replying to for > not referencing their names (i didn't have the > time). You ask us to take the time to implement a new mechanism of dubious value. Meanwhile, you won't take the time to mention our names so that we can at least go quickly to the part of your email that concerns us, nor break it up into individual pieces so as to at least preserve the subject lines. Talk about cooperating.... > spam is something we can eliminate by > changing our personal behaviors and expectations > and cooperating. Long ago that might have been true. Welcome to the Everlasting September. > and it can happen gradually. It will probably have to! As for the lengthy conglomeration of your replies to other messages, forget it, I for one am not slogging through that mess, even though I see you replied to something I wrote. -- Dave Aronson, Senior Software Engineer, Secure Software Inc. Email me at: work (D0T) 2004 (@T) dja (D0T) mailme (D0T) org (Opinions above NOT those of securesw.com unless so stated!) WE'RE HIRING developers, auditors, and VP of Prof. Services.