[Mailman-Users] The economics of spam

[Rich Kulawiec]

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 listserv at peach.ease.lsoft.com)
	asrg (via asrg-request at irtf.org)
	spamtools (via spamtools-request at 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.