At 17:03 -0400 4/23/03, Kee Hinckley wrote:
I'm not fond of whitelisting myself, we support it, but we consider
it a patch to deal with a failure in the system. The inability to
nail down "identity" is the primary reason I don't like it.
I can see how a whitelist can be useful in a world where other, more
precise measures, do not provide perfect protection... like the world
we are in right now. Primarily, a whitelist built on rather simple
heuristics could assure delivery of things that should be delivered.
Cooperation between clients and servers is needed to pull it off
properly, but that seems workable.
Rule: Allow all whitelisted senders to pass through without
additional checks, then treat skeptically whatever is left via
traditional processing.
it bootstraps easily:
A writes to B B should be added to
A's whitelist
B does not reject[1] the message from A A should be added to
B's whitelist
The likelihood of spammers capturing a large percentage of all (A,B)
interactions and then generating forged messages to likely (A,B)
pairs is very low, since these are private interactions not seen by
others.
The list might carry a status column for "auto-added" or "blocked and
don't re-add" when unwanted senders with persistent identities are
noted.
I am interested in mail client--mail server collaborative solutions.
If anyone else is similarly interested, please contact me off-list.
====
[1] "reject" -- somehow tell the system you don't want this by filing
in special "spam" folder or clicking "Spam" button on mail client UI
or forwarding to special processing address at the mail host
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg