I notice a recurring theme in this massive outpouring of concern about SPAM: It is that a lot of people have put a lot of time and effort into attempts to solve the problem, and we should all keep in mind that we are all coming late to the party, and are generally suggesting stuff that has been seriously considered and rejected. It is very nice that all this effort has been provided, but where is the documentation of the results, so the rest of us might be able to review the archives and avoid repeating prior efforts? Looks like a good place to build a useful archive. It seems to me that documentation of negative results could be very profitable if published in an RFC (or RFC series), or RIA (Rejected Ideas Archive series), or something like an old junk yard where we can refer people to quickly deal with "new" ideas that have failed the test of time. Let GOOGLE find the flakes of gold. Just consider how much time and effort is going to waste here and now;-)... We either have to re-plow these fields over and over, or we can make some notes to leave for people who wander this way next time. One idea that I believe has met the test of time is the Marshall Rose SPAM personal control system that simply scans every incoming message to see if it is on his personal list of acceptable correspondents. If YES, it gets through; If NO it is held in isolation and a reply is sent to the sender asking to confirm that it is a real message and is not spam. The trick is to use some positive filtering along with the negative filtering, and assuring that nothing is simply sent to dev/null without further attention. I suspect that there are various categories that are used to segregate mail into various interesting categories, but I have never asked about this aspect. I use a more or less manual version of this by locally filtering everything into known correspondent folders, or into specific spam folders or The Trash. All mail with from strings like "mail.com", "mail.net" "kr.com", "cn.com" "mail.kr", "mail.ru", etc, go straight to trash where I do a really quick manual scan for anything that might be from someone I know. The patterns are pretty obvious to the naked eye. Hardly anyone using such FROM addresses ever has anything useful to say to me. this is not racial or nationality discrimination, but a historical fact that I just happen to not have any corespondents who use those kinds of domain names. If I ever get some useful mail from any of these addresses, I create a filter for it to be filed in some folder that is not pointed to the trash bin. I would use Marshall's tools if only I had the right Operating System environment. Getting to that point is on my long term list of objectives;-)... My huge set of (800+) Eudora filters now catch all spam and keeps it out of my working folders. A very few non-spam messages lend in my trash bin for manual extraction. This method builds over time to become better and better, over time. Automating it further is a design goal. The main lesson I take from this is that filtering is a very personal kind of thing, and thus anti-spam tools and systems need to also be tailorable to individual circumstances. It also helps to have your active filters tell you when they are no longer catching anything so they can be deleted or parked out of the traffic lanes. These ideas are freely broadcast for use by anyone that wishes to use them. A copy of this release to the public will no doubt be held by IETF in the IETF discussion list archives. Cheers...\Stef >At 01:14 PM 8/14/02, Daniel Senie wrote: >>First, I think that my method described in my e-mail "Re: Why spam >>is a problem." would address some pretty big issues. As far as spam >>filtering, this would allow users to reject e-mail coming from >>users that actually exist on a mail server for a domain e-mail is >>coming from. > >It also will block email coming from embedded devices, alerting you >that your UPS has a bad battery, or sending you firewall logs, etc. >There are MANY devices with SMTP embedded in them, which adhere to >the RFCs, and which will be severely broken by your proposals. > >As many folks have already said on the IETF list, this is NOT a >subject that can or should be "solved" with a quick fix. Though the >IETF community loves to toss ideas out and have big discussions of >this sort, they tend to generate a lot more heat than light. > >Many people inside and outside the IETF have spent a great deal of >time on the spam issue, and have discussed and dismissed a great >many proposals and ideas, including many of the ones that have been >tossed about on this list. > >If there is a desire to approach the technical and/or political >aspects of spam within the structure of the IETF, then one or more >BOFs should be organized, mailing lists set up, and the normal >process followed. > >To continue the spam discusion on the ietf list does nothing more >than point out why we call it spam in the first place. Go back and >watch the Monty Python sketch. You'll note the discussion drowns out >everything but spam. > > >----------------------------------------------------------------- >Daniel Senie dts@senie.com >Amaranth Networks Inc. http://www.amaranth.com