Re: Comments on IM2000

(Some quick clarifications, as I really need to give a full response
more thought.)

>On Wed, Apr 13, 2005 at 03:01:32PM -0000, James Craig Burley wrote:
>
>> That definitely has collateral damage.  I don't use any traditional
>> RBLs, though I do block email with envelope senders of known spammers
>
>But that's stupid, because the envelope sender cannot be trusted!

I didn't explain that very concisely, I guess.  I block email with
envelope senders *known* to *belong* to spammers.

In that sense, pobox.com might be "0wned" in the sense of being
joe-jobbed, but so is my jcb-sc.com domain name.  I don't block those.

The list I subscribe to is a list of domain names (and email
addresses, apparently) literally *owned* by spammers.

Strictly speaking, a domain name like ownedbyspammer.com can be
"forged" by someone else, but blocking that email is hardly a problem,
any more than recognizing that "HELO [*anything*.]ownedbyspammer.com"
in an SMTP session is sufficient to tell the SMTP server that *all*
email being submitted during that session is highly likely to be spam.

>> But I really don't end up *seeing* lots of spam, because my primitive
>> MTA (funnily patched qmail) dispenses with most of it via a
>> combination of very trivial tactics -- giving a multi-line greeting in
>> most cases, tarpitting multiple RCPTs, and a few other very simple
>> content-based things done on the fly -- which somehow conspire to
>> rebuke most older spam software
>
>But your definition of spam is "sent by a program which does not correctly
>implement Internet RFCs".

No no no no no!  My definition of "spam" is everyone else's -- UBE.
It so happens that a substantial % of UBE-sending software can't
tolerate trivial variations in SMTP server responses, such as
multiline greetings.

>However, this means you'll refuse to accept mail
>from "good" mail sources which also happen not to implement the RFCs in the
>expected way.

No I won't.  *Their* clients will just have trouble transmitting email
to me.  That's *their* problem -- I haven't "refused" it at all.

>And besides, if your methods really are effective and lots of
>people start to implement them, then the spammers will just "correct" their
>code.

Well, of course.  That raises the bar for them.

>You are just helping to force spammers to write better software!

Please, ratchet down the rhetoric.  I am not "helping" them in any
way, shape, or form.

I am just "lucky" in that maybe 99% of the spam heading into my server
is either a) misdirected, and thus bounced, b) obviously "owned" by a
known spammer, c) delivered by an SMTP client that exits upon seeing a
multiline greeting or HELO response, or d) delivered by an SMTP client
that gives up after more than a minute or so waiting for a RCPT TO
response.

All of the "fixes" spammers need to apply to jump those hurdles
represent additional cost, especially writing and deploying new
software.

>> What I mean is that, in a greylisting-type system, it is assumed (and,
>> often, correctly so) that a second or third attempt to send an email
>> lowers the probability that it's UBE.
>
>Only because spam senders today don't bother to perform retries. If it
>becomes worth their while to do so, they most definitely will. It is, after
>all, not difficult.

No, as is widely recognized.  It's a temporary tactic, one which
raises the bar in terms of increasing the expense of sending UBE (and
the visibility that one is doing so), which is kinda the whole point
of IM2000, right?

-- 
James Craig Burley
Software Craftsperson
<http://www.jcb-sc.com>