----- Original Message -----
From: "David W. Tamkin" <dattier(_at_)ripco(_dot_)com>
To: <procmail-users(_at_)procmail(_dot_)org>
Sent: Thursday, December 13, 2001 4:20 AM
Subject: Re: Certified Mail Delivery agent
Mark <admin(_at_)asarian-host(_dot_)net> wrote,
| I hate to burst someone's bubble, but this whole concept is flawed from
| the get-go.
Clearly Mark and I are on the same side of the greater issue,
I got the same impression. :)
but I
disagree with this:
You may think you are playing it safe when you are individually
allowing email addresses from, say, "hisdomain.com"; but what you have
in fact done, is allow spammers access | to your mailbox with a key
that can be created as easily as typing an email address.
Not really. No spammer keeps a database of the keywords or tricks for
getting through each address's defenses. (If they did, a greenlist
wouldn't work either.)
True enough.
[Some people's uses of "whitelist" and "greenlist" are the transposition
of the way I use them. As I use the terms, a whitelist works like this:
if the sender is on the whitelist, accept the message; if the sender is
not on the whitelist, reject it as spam. A greenlist works like this: if
the sender is on the greenlist, accept the message without further
testing; if the sender is not on the greenlist, examine the content (not
necessarily just the body, but perhaps also the subject and the routing
and a blacklist/redlist of senders from whom any mail is unacceptable) to
determine whether it seems to be spam or not. What to pick as the
"sender" of a message is yet another question.]
I concur with your definition of whitelist and greenlist.
Personally, I only use a blacklist (via the sendmail access database) and a
user-participated would-be blacklist. That is, I have opened a special
address at the server to which users who feel they have received spam can
forward this spam to. Then, ever so frequently, I use the human eye to
determine which of those emails really is spam, and whether domains or
IP-ranges need to be blocked. I like that co-operative approach. Instead of
making an overly zealous determinination what is a spam, users get to have a
choice in what they forward as spam. Mind you, a choice, not a voice. :) I
ultimately make the determination what gets blacklisted or not.
Naturally, I have a few Perl scripts to sift out IP addresses and relays
from /var/log/maillog and such, but the decision remains a human one. I
never send a message back to spammer, not personally or automated. That
usually only tells them they have a responsive address. I just add their
name with a REJECT in the access database; then, next time they connect,
they run into the ever so rigorous "550 Access Denied" wall; that, I
believe, is a stronger message than actually sending something. :)
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail