On Sun, Jan 04, 2009 at 03:56:42PM -0800, Jan Steinman wrote:
> Is it really necessary to take this arrogant and abusive tone?
Consider it exasperation at seeing this FUSSP brought up yet *again*,
long after it was staked through the heart and buried at a crossroads.
Please see:
http://www.rhyolite.com/anti-spam/you-might-be.html#e-postage
for background on and examples of FUSSPs.
If you (rhetorical you) want to self-educate and to potentially apply
yourself to addressing the problem, then by all means, please do.
But this list isn't appropriate; I suggest joining some/all of these:
spam-l (via lists...@peach.ease.lsoft.com)
asrg (via asrg-requ...@irtf.org)
spamtools (via spamtools-requ...@lists.abuse.net)
AND reading most of their archives, especially spam-l, before attempting
to promulgate your favorite tactic/strategy. (I'm not the only one with
a short fuse when it comes to dealing with the same known-failed idea for
the 47th time, although I will readily admit that some others show far
more patience than I do. Maybe they have more -- or better -- brandy.)
---Rsk
p.s. As a small courtesy, and by way of compensation, let me try
to provide some minor assistance to potential future contributors by
enumerating a few of the fundamental design errors that immediately doom
some "anti-spam" ideas:
- redefining abuse
- redirecting abuse
- amplifying abuse
- fighting abuse with abuse
- failure to consider scaling issues ("what if everyone did this?")
- failure to consider adoption issues ("what if everyone didn't do this?")
- failure to consider counter-measures ("what if spammers read RFCs?")
- generating yet more SMTP traffic
- presumption of spammer honesty/compliance/acquiescence
- allowing unknown third parties to generate significant amounts
of outbound traffic to destinations of their choosing
- reliance on legislation and/or law enforcement
- forcing effort and costs of abuse control onto third parties
- drastic underestimation of spammer resources and abilities
- presumption of secure network endpoints
There's more, of course, but a few minutes' contemplation of these is
sufficient to understand why some approaches (e.g., opt-out, SPF, C/R,
SAV, BlueFrog, and yes, e-postage) are not going to work regardless
of how they're implemented, and why attempts to implement them make
(or would make) the spam/abuse problem considerably worse.
------------------------------------------------------
Mailman-Users mailing list
Mailman-Users@python.org
http://mail.python.org/mailman/listinfo/mailman-users
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives: http://www.mail-archive.com/mailman-users%40python.org/
Unsubscribe:
http://mail.python.org/mailman/options/mailman-users/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
