Subject: Re: [Asrg] Turing Test ...

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Sun, 6 Apr 2003 11:03:20 -0700

We could probably do a bit better without the sarcasm.

We all know the theory of smtp. The problem comes when you want to start
enforcing protocol features that we previously discretionary. Then you get
problems with broken legacy mailers.

Checking replyto and whitelisting does not by itself provide a solution.

But construct the message ID using a shared secret and hmac and a server can
know that any message referencing it is a legit reply and should be
whitelisted.

BTW I have prior art on this technique from1993 and others probably have
earlier so the patent trolls need not go for their lawyers.

 -----Original Message-----
From: 	wayne
Sent:	Sun Apr 06 08:39:04 2003
To:	[email-masked]
Subject:	Re: [Asrg] Turing Test ...

In <[email-masked]> Claus Assmann <[email-masked]>
writes:

> Maybe I should make it more clear: you send a question to sendmail.org,
> you can get an answer from esmtp.org, some university, some Unix
> vendor, some other domain...
> 
> Hence your original mail must already include a "token" which allows
> the reply to go through without depending on the sender address
> (domain).

Hey, I have an idea!

You want to identify the message, so this "token" should be placed in
a header called, uh, how about "Message-ID:".  In order to make this
message-id work, you would want to make sure that it is unique to
every message that you send.

Then, when someone replies to this message the MUA could create a new
header, uh, let's call it "In-Reply-To:" that contains this
message-id.  That way we know that the reply was related to a message
that we sent.  Since the message-id is unique, it will be hard for a
spammer to guess and you could decide how long keep track of
message-ids so even if a spammer got ahold of one, it couldn't be used
for long.

The big plus of having things like a "message-id" and "in-reply-to"
headers would be for mailing lists like this.  A mail reader could tie
all the messages together into threads making it much easier to follow
the discussions.  To help with making the threading of messages more
robust, you could add a header that lists all the message-ids of all
messages involved in this set of branches of a thread.  Maybe we could
call this header something like "References:".

Wouldn't it be great if something like this had been created become
standard decades ago, so that even MicroSoft and Window mail systems
would follow such a standard?  (Hint to Phillip Hallam-Baker, Eric
D. Williams, etc.)  Or, at least didn't create damaged In-Reply-To
headers by breaking the message-id into two parts.  (Hint to Art
Pollard)

-wayne

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: wayne <[email-masked]>
Date: 06 Apr 2003 15:30:32 -0500

> We could probably do a bit better without the sarcasm.

Agreed, and point taken.

However, I think it would be a bit better if a very few high volume
posters such as yourself would start adding either In-Reply-To or
References headers just like the vast majority of posters do.

Pardon my ignornce, but is it your MUA that doesn't generate these
headers, or your MTA that strips them?  I guess I'm presuming that you
aren't deliberately removing the headers for some reason....

> problems with broken legacy mailers.

While I won't presume to speak for "we", I will say that I think that
getting legacy mailers to support well long supported and understood
headers is vastly easier than getting everyone to add anything new.

-wayne

---

From: Kee Hinckley <[email-masked]>
Date: Sun, 6 Apr 2003 18:06:12 -0400

>References headers just like the vast majority of posters do.

Sure, everyone can just run right out and patch the binary.

>headers is vastly easier than getting everyone to add anything new.

Welcome to the problem of updating MUAs.  Where there's no perceived 
benefit, the changes don't get made.  All the commercial mail 
products seem to find it better to thread by subject--certainly it 
makes more sense to do so in this forum, where the conversations go 
on forever (it seems), but the topic constantly changes.

But back the subject.  Would whitelisting by plain message-id really 
work?  Certainly seems less intrusive than most systems.  I'm not 
sure what you'd want to do with web archives of conversations though. 
On the one hand, you'd like people to be able to respond.  On the 
other, you don't want to feed message-ids to spammers.  Probably 
you'd recommend stripping them.

Would you see it as a preliminary way of doing an email address 
whitelist, to just bypass the need for an initial check--and 
subsequent new messages from the person would go through as well? 
And do most MUAs generate their own Message-IDs?
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: wayne <[email-masked]>
Date: 06 Apr 2003 19:06:58 -0500

In <p06000d05bab652399315@[192.168.1.104]> Kee Hinckley <[email-masked]> writes:

> >posters 

Of course, "a very few" != "everyone".  Also, depending on the system
being used, this may be a configuration option.  I don't know enough
about Phillip's situation to know.

>                                       All the commercial mail products
> seem to find it better to thread by subject--certainly it makes more
> sense to do so in this forum, where the conversations go on forever
> (it seems), but the topic constantly changes.

Well, the MUA that I use can and does thread by subject when there
isn't a In-Reply-To: or References: header.  Heck, it will also use
the timestamps to help out.  It still isn't as good because messages
do not come in with a perfect order.

In what way do you think the threading can be done better by subject?

> work?  Certainly seems less intrusive than most systems.  I'm not sure
> what you'd want to do with web archives of conversations though. On
> the one hand, you'd like people to be able to respond.  On the other,
> you don't want to feed message-ids to spammers.  Probably you'd
> recommend stripping them.

I don't believe in absolute blacklisting or whitelisting.  I really
like the SpamAssassin approach of combining many different
indicators.  For my use, I would want the bonus for having a
message-id to decay pretty quickly with time.  Someone who replied to
a message of mine that they saw in an archive from last year would not
be given any bonus by me.

> subsequent new messages from the person would go through as well?

SpamAssassin's auto-whitelists/blacklists work by using spam scores
from previous emails that I have received from you to influence the
spam score of your current message to me.  The initial bonus by having
a valid in-reply-to message-id from me would always be a factor, but
the influence would decrease as I get more information about the kinds
of email that you send to me.  If SpamAssassin guesses wrote with it's
auto-whitelist/blacklist, I can easily add a manual
whitelist/blacklist entry, but I rarely have to do that.

> And do most MUAs generate their own Message-IDs?

To the best of my knowledge, the MUAs are supposed to add the
message-id, but MTAs can add missing ones.  The latter, however, is a
pretty good sign of spam.

-wayne

---

From: J C Lawrence <[email-masked]>
Date: Sun, 06 Apr 2003 18:24:56 -0700

On 06 Apr 2003 19:06:58 -0500 

> pretty good sign of spam.

Correct, most MUAs generate Message-IDs, and when they are missing, most
deployed MTAs will add one of their own devising.  Note however that
while I haven't checked RFC 2822 in this regard, under RFC 822
Message-IDs are not REQUIRED.  I get a rough handful of otherwise valid
messages per year on my lists without a Message-ID.

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
[email-masked]               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Chuq Von Rospach <[email-masked]>
Date: Sun, 6 Apr 2003 19:05:56 -0700

On Sunday, April 6, 2003, at 03:06  PM, Kee Hinckley wrote:

> benefit, the changes don't get made.

where there are significant benefits, the changes still don't get made. 
a good percentage of open relays being used by spammers are sites still 
running sendmail 8.9, from back when relay was default on. Despite all 
of the security holes closed since then, and huge performance increases 
-- they're still running it.

Which leads to assuming all of those sites fall into one of three 
categories:

1) they want to be open relays.
2) they don't care.
3) they don't know any better.
4) they ain't home. the admin who set things up isn't there any more, 
and neither is
	anyone else.

(1) is likely to be the smallest percentage. (2) through (4) are all 
variations of the same general thing, and if nothing YET has convinced 
them to upgrade, what possible thing can this group come up with that 
would change their mind, other than making their software 
non-functional. And then, they'd have a cow (if they even noticed), and 
since any change to non-compatible systems would require a transition 
period and/or a gateway, would it really make a difference?

I think the continued existance of open relays and open proxies is the 
best argument against systems that require updates to the sending 
systems: if people can't be bothered to make basic security and 
technical updates from sendmail 8.9, expecting them to upgrade for 
anti-spam changes is unrealistic. It's not gonna happen, unless it's by 
virtual gunpoint.

(now, me, I personally wouldn't be too against a decision to stop 
accepting e-mail from sendmail versions prior to, say, 8.11.0 after 
some given date, just to force that issue. But that's some other 
discussion -- I am surprised, however, that nobody seems to have tried 
forcing this issue by rejecting e-mail from seriously out of date 
servers, just to get their attention...)

This seems to lead back to solutions that can be implemented at the 
receiving end, either server-based or client-based. Any solution that 
requires "they" cooperate has to answer how we plan to find out who 
"they" are, and then get "them" to go along with it.

That includes, by the way, "tehy" being major ISPs like AOL or 
Earthlink. "They" may not be  running sendmail 8.9, but anything that 
requires them to implement better be worth the time and energy to do 
so. The "nuke bounces" discussion, for instance, impacts all of AOL's 
email, since they'd have to entirely rearchitect their systems. What's 
in it for them? Something like that seems like a basic non-starter, 
unless AOL comes on board early. And I dn't see any real advantage to 
THEM to do so. (actually, I don't see much, if any, real advantage to 
that proposal at all, but that's different from it being a 
multi-million dollar, multi-man year, 
god-knows-how-many-calendar-months project for AOL to do. What's the 
ROI on that kind of project for them? If you can't asnwer it, it's 
dead, Jim)

---

From: Brad Spencer <[email-masked]>
Date: Sun, 06 Apr 2003 21:36:38 -0500

At 07:05 PM 4/6/2003 -0700, you wrote:

>where there are significant benefits, the changes still don't get made. a 
>good percentage of open relays being used by spammers are sites still 
>running sendmail 8.9, from back when relay was default on. Despite all of 
>the security holes closed since then, and huge performance increases -- 
>they're still running it.
>
>Which leads to assuming all of those sites fall into one of three categories:
>
>4) they ain't home. the admin who set things up isn't there any more, and 
>neither is
>         anyone else.
>
>would change their mind, other than making their software non-functional. 
>And then, they'd have a cow (if they even noticed), and since any change 
>to non-compatible systems would require a transition period and/or a 
>gateway, would it really make a difference?

I got into anti-spam by being the operator of an abused open relay.  I'd 
consider it to be a favor to me to blocklist it, when it was open, I'd 
consider it a favor to reject email with a disk-full message (so email 
would back up in my queue) when blocklisted.  I think that would be fair to 
all with open relays (even if they didn't.)  That isn't going to affect the 
truly clue-impaired but it might reach some of the mildly clue-impaired.

(There's really a more basic system design problem: software is distributed 
that can be predicted to become obsolete or dangerous.  That software does 
not include any automated mechanism for checking for new versions - that's 
left up to the initiative of the operator.  Sure, lambaste the stupid 
operators - that doesn't solve the overall problem nor their problem.) (All 
in parentheses because it's parenthetical.)

For the reasons you mention they won't upgrade.  I advocate an anti-spam 
action that does nothing to help these people but that does reduce their 
overall effect - dilute the pool of open relays sufficiently with fakes and 
the real ones tend to no longer matter.  The validity of the approach can 
be seen by logic.  Success of this approach does require a number of fakes 
equal to or much greater than the number of true open relays (the exact 
number depends on spammer behavior.)  That number is attainable.

---

From: Chuq Von Rospach <[email-masked]>
Date: Sun, 6 Apr 2003 20:42:00 -0700

On Sunday, April 6, 2003, at 07:36  PM, Brad Spencer wrote:

> I'd consider it to be a favor to me to blocklist it, when it was open,

Me, too. In fact I screwed up a few weeks ago (god bless sendmail's 
queuemode=defer) and left a relay open (I copied a config from a 
machine behind a firewall to a machine open to the world). The bad news 
is the spammers found it amazingly quickly. the good news was that 
spamcop found the spammers even faster, and we got that puppy shut down 
before major bad things happened (just minor). Even more fun, we set 
the thing to accept and discard the spam from the spammer, so it ate a 
few tens of thousands of messages before he figured it out and went 
away.

In my case, the blacklist caught a problem much faster that I would 
have. While I don't by any means consider all blacklists my friend (or 
well run, or useful, or objective, or whatever), they're a useful tool. 
But not everyone thinks that way. Some folks don't want to be 
responsible. Some people don't want problems like that interfering with 
their priorities. Some folks (John Gilmore at hoptoad, for instance) 
see it as a violation of their rights... ohwell. But I'm all for a 
well-run blackhole setup, even when it makes my life inconvenient. 
Especially then, actually.

> (There's really a more basic system design problem: software is 
> distributed that can be predicted to become obsolete or dangerous.  
> That software does not include any automated mechanism for checking 
> for new versions - that's left up to the initiative of the operator.  
> Sure, lambaste the stupid operators - that doesn't solve the overall 
> problem nor their problem.) (All in parentheses because it's 
> parenthetical.)

(you mean, like apple does for MacOS X? but even then, there are 
issues. If you're running a production server, you're frankly an idiot 
to let a vendor or a software tool decide what gets upgraded and when. 
Small systems? sure. but larger organizations need to know what's going 
to break, and what won't, which means some time testing and evaluating 
on non-production hardware. And in many environments, those machines 
CAN'T talk to the update service because of firewall restrictions. 
Which is a feature. What works fine for some enviornments is a bad idea 
for others. Ultimately, if it's a server, the people who operate that 
server need to make the decisions about what to upgrade, and when, 
because there are going to be dependencies that only those people will 
understand and be able to make decisions about. Imagine the fun, for 
instance, of installing an OS patch that breaks a system that's being 
depended on for quarter-end financial processing, at quarter-end. The 
real world stops here.. Again, I think this is a minor case of "the 
entire world isn't like where you're at" -- I live in so many 
environments these days, and I deal with people in so many environments 
on a global basis, that I've had this driven into my skull with red hot 
pokers through the eye sockets. Since my group has just finished up a 
project involving dealing with e-mail and <mumble> languages, and is 
starting to work on extensions to properly support some other stuff I 
can't talk about, I've gotten very aware of the joy of dealing with 
international e-mail. Last I looked, about the only place I don't have 
at least a fingernail in is the space station; I even have subscribers 
to one list down in Antartica....)

> For the reasons you mention they won't upgrade.  I advocate an 
> anti-spam action that does nothing to help these people but that does 
> reduce their overall effect - dilute the pool of open relays 
> sufficiently with fakes and the real ones tend to no longer matter.

The problem iwth that is that, well, spammers aren't dumb. I was 
suprised at how quickly the spammer found my open relay. I was even 
MORE suprised at how reactive he was to my taking it down and bringing 
it up. (twice; I didn't fix it quite right the first time. grump), and 
then again the third time, once it was really fixed but acting as a 
byte bag to him. And then how quickly he figured it out and went away 
again. Honeypots are a useful tool here, but the smart spammers already 
have them figured out, and it seems every "N"th message is a test to 
make sure the relay isn't honeypotting. stupid spammers fall for them, 
of course, but this is an arms race. stupid spammers buy smarter tools 
over time.

But basically, you're right. I was having that discussion with a friend 
(also on this list) offline. Effective tools in scope for this group 
have to be either client-based, or receiving-server-based. You have to 
clean up your own yard before you can complain about the rusting cars 
in the neighborhood, and don't expect them to be removed until the city 
shows up with a tow truck (and frankly, we're living in a city that 
doesn't tow beaters -- who has the right to say "you stop that!" and 
make it work? Basically, nobody does. that was the ultimate failure of 
USENET: rules require either cooperation or policemen, and if you have 
neither?)

So, to me, if it requires server-side change, it's a non-starter, 
unless someone can tell me the major ISPs are on board. Until they are, 
anything to be done, has to be done at the receiving end, which WE 
control, and through education and encouragment, can evangelize out to 
the rest of the net. And that, to me, means better whitelisting, better 
blacklisting, better filtering, honeypotting tools, and the like. Most 
organizations are going to wait and see how they work on a small scale 
before committing to implement them into larger situations -- and that 
includes ISPs. And can you blame them? An infrastructure change to 
Earthlink can cost them tens of millions of dollars to implement; for 
AOL, much more. They aren't going to do what isn't proven. So it's 
going to have to be proven by the smaller users first, and that means, 
it can't be a solution that requires ISP buy-in up front.

>  The validity of the approach can be seen by logic.  Success of this 
> approach does require a number of fakes equal to or much greater than 
> the number of true open relays (the exact number depends on spammer 
> behavior.)  That number is attainable.
>

And the honey pot has to continue to work once spammers implement their 
"test every N'th email to make sure the relay is still working" code 
widely. Once honeypots become common, so will anti-honeypot technology. 
And I think honeypots are easier to work around than they are to 
protect from spammers hunting them; their greatest advantage now is 
they're rare enough that most spammers probably aren't worrying about 
them much yet.

So if you have a honey pot, how do you make it tempting to a spammer 
who's going to test that ti's working, while still make it effective as 
a honeypot? Assume, for instance, that the spammer has, say, 50 AOL 
accounts, 100 hotmail accounts, and 100 MSN accounts, all of which 
forward to his real hideaway, and he tests a honeypot by sending every 
rand(5000) email to one of his own tester addresses and validates it 
gets delivered. If too many disappear, he shuts down use of the address 
and goes elsewhere....

---

From: Vernon Schryver <[email-masked]>
Date: Sun, 6 Apr 2003 21:53:13 -0600 (MDT)

> From: Chuq Von Rospach <[email-masked]>

> ...

There's a fifth category, or perhaps a flavor of the last 3:
  - the system is well maintained and might need to do some authorized
   relaying, perhaps because it is a "smart host," in a DMZ, or is an
   MX secondary,, but is sufficiently misconfigured that it in relays
   one of the ~18 problem cases.

Whether it relays in some unauthorized cases is not obvious to its
owners, because the open door might do some good and does no harm
until and unless it is discovered by spammers and not much harm even
then.
(Yes, I've seen systems clobbered by loads of relay spam, but that
was long ago when ratios of computer/network speed were 10 or more
times smaller than they are now.)
(Yes, I've heard of RSS, ORBS, ORDB, and others.  They've been listing
10**5 open relays forever with no significant change.  Like most DNS
blacklists, their bark (supposed popularity according to some) is far
larger than their bite (true popularity or amount of mail they bounce.)

I figure that at least 1% of all SMTP server installations or upgrades
will always suffer this sort of problem.  Since there are far more
10**7 SMTP servers, they need to be updated or replaced and so
(re)configured at least annually, there will always be more than 10*5
open relays.

Similar but about 100 times more discouraging quantitative reasoning
applies to open proxies.

> ...
> ...

I may have lost count, but I think all of the solutions that have been
proposed and defended at length in this mailing list have assumed
"they" or everyone will do something starting with installing new
software and then spam will stop.  That is certainly true of
challenge/response, authentication and/or encryption, no-bounce,
message pull, honeypots, and sender-pays systems.

Notice that the "bounces should be outlawed" and "relays are not
needed" positions could be but are never implemented at the mail
receivers of their advocates.  No great effort is needed to reject
bounces (e.g. from Mailer-Demon) or mail that has been relayed (many
Received lines) when it is seen by an MUA or MTA.

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Brad Spencer <[email-masked]>
Date: Mon, 07 Apr 2003 08:01:09 -0500

At 08:42 PM 4/6/2003 -0700, you wrote:

>And I think honeypots are easier to work around than they are to protect 
>from spammers hunting them; their greatest advantage now is they're rare 
>enough that most spammers probably aren't worrying about them much yet.

First the spammers have to do that.  I delivered something like three test 
messages in February.  I trapped spam into March from the spammer - all 
that while I wasn't even delivering his subsequent test 
messages.  Nonetheless he continued to send spam.  There are dumb spammers, 
and last year Ralsky was one of them.  He trusted the Moscow honeypot so 
much he used to relay reports from spam servers to himself.

I basically only trap relay test messages - I don't routinely deliver 
them.  The ones in February were to see what spam would follow if I did 
deliver the message.  The only defense I can see against a system that 
traps relay test messages is to stop testing it.  If it IP hops then 
eventually the only defense is to stop testing that entire IP 
range.  That's what I want - it is  a success for me.  The spammer has a 
measure of protection if he relay tests through an open proxy - I don't 
know his real IP if he does that - but his dropbox address still is a 
vulnerability. An open proxy honeypot can be the spammers downfall in this 
case.

What you did by accident can be done on purpose.  The spammer found you 
quickly because he constantly sends relay tests (the sendmail logs should 
reveal the source IP and the destination of the test - look for the first 
relayed message through it.)  The speed with which the spammer found your 
new open relay and abused it is his vulnerability - anybody with a spare IP 
in the range the spammer tests to find open relays can catch him as soon as 
he sends his test.

I'll also note that although there are something like 18 known 
vulnerabilities for an MTA what I trap is tests looking for the simplest 
vulnerability: plain old open relay.  The spammers would be far more 
obvious if they did all 18 tests.  I can't prove I'm not on a re-test list 
(check to see if the IP is still open.)

As a side note I'm happy to see I've been tested again today by the spammer 
whose test I delivered in February.  Short memory, perhaps.  Test from 
162.39.58.75, to [email-masked].

>So if you have a honey pot, how do you make it tempting to a spammer who's 
>going to test that ti's working, while still make it effective as a 
>honeypot? Assume, for instance, that the spammer has, say, 50 AOL 
>accounts, 100 hotmail accounts, and 100 MSN accounts, all of which forward 
>to his real hideaway, and he tests a honeypot by sending every rand(5000) 
>email to one of his own tester addresses and validates it gets delivered. 
>If too many disappear, he shuts down use of the address and goes elsewhere....

Cross that bridge when I come to it.  Fred Woods is working on a central 
database of spammed IP addresses.  If the spammer re-uses his captive 
address frequently that address will show up as being hit more often.  Once 
you know his captive address you make sure to deliver the spam to 
him.  It's not likely to be an AOL address - AOL stops incoming spam so he 
won't know if the relay stopped the spam or if AOL did. I also in many ways 
don't care - the goal is to end spam, not to trap spam in honeypots.  If 
the spammer is chase away form an IP and ultimately from a range of IPs 
then that is a win.  That would mean you could have a true open relay and 
not have it abused because all of the spammers know not to test the IP.  (I 
don't advocate having a true open relay - I'm just illustrating the 
desirability of the effect.)  If ISPs would learn about relay tests (it's 
shocking and a shame that they don't inherently know about them) then 
reporting a relay test would get the spammer account closed (at a 
minimum.)  If ISPs really learned about relay (and proxy) tests they'd act 
against tests from and to their space - that would make honeypots trivial 
and unnecessary.

If ISPs got truly clued then when a honeypot detected a spammer's captive 
address the ISP could do creative things when that address was reported to 
the ISP.  Right now most ISPs, if they do anything, just close the 
account.  I'd far prefer they would leave the account open but divert email 
addressed to that account elsewhere (like /dev/null, as far as the spammer 
knows.)  That way the spammer would waste some tests before he finally 
figured out the diversion.  The ISP could also go back through its logs and 
know every open relay the spammer found using that dropbox address.

I'm anti-spammer.  I look for ways to interfere with spammers.  That I can 
do it using an ordinary .edu system and my home system (which isn't tested 
very often at the moment) is a big clue that the same approach can be used 
almost anywhere.

This trapped message puzzles me.  It's probably a test but my IP is well 
hidden if it is.  Maybe it's in the sender name or the 
X-precedence-Ref.  The message-ID was added by my MTA - nothing there:

Date: Sat, 5 Apr 2003 03:59:02 -0800
From: [email-masked]
Subject: Reduce Your Holiday Debt
To: [email-masked]

<a href="http://ecomms.org/debt/?N=30010"><img 
src="http://ecomms.org/ad-110.jpg"></a><BR><BR><A 
HREF="http://ecomms.org/remove/">remove

---

From: Kee Hinckley <[email-masked]>
Date: Mon, 7 Apr 2003 03:10:05 -0400

At 9:36 PM -0500 4/6/03, Brad Spencer wrote:
>I got into anti-spam by being the operator of an abused open relay. 
>I'd consider it to be a favor to me to blocklist it, when it was 
>open, I'd

I'd consider it a much larger favor to send email to the site 
administrator *first*, and blacklist only if that has no effect.  For 
any site that is actually being administered, that's going to cleanup 
the relay far faster than blacklisting would.  Blacklisting relies on 
enough people subscribing to the blacklist that eventually someone at 
the site won't be able to send email to someone they care about, will 
recognize what the problem is and report it to the site admin, who 
will then go to the blacklist site, figure out what the problem is 
from there and fix their system.

That's an awfully inefficient way to communicate a problem. 
Certainly puts a different light on the altruism of blacklist 
operators.
-- 
Kee Hinckley
http://www.messagefire.com/          Junk-Free Email Filtering
http://commons.somewhere.com/buzz/   Writings on Technology and Society