RE: IETF announce list and spam filtering
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
I would use Marshall's tools if only I had the right Operating System
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
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
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.
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
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
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(_at_)senie(_dot_)com
Amaranth Networks Inc. http://www.amaranth.com