Re: SPF is harmful. Adopt it.

JdeBP> First: Recipients can choose to give different priorities to
JdeBP> notifications according to whether they "know" the message
JdeBP> stores that those notifications reference.  So a recipient
JdeBP> could instruct his/her recipient MUA that it "knows" AOL's 
JdeBP> and Sally's message stores.  "New" mail on any other message
JdeBP> stores would then be flagged as residing on an "unknown"
JdeBP> message store, when the list of "new" mail is displayed.

ILT> This is not different from SMTP.

Yes, of course it is.  SMTP-based Internet mail is a "store and forward"
system.  A recipient cannot tell the difference between a hijacked machine
running an SMTP Relay puppet and an unknown MTS forwarding mail.  IM2000,
_not_ being a "store and forward" system, does not have this ambiguity.

JdeBP> Second: Recipients, and recipient notification owners, can
JdeBP> arrange to exchange information with one another about 
JdeBP> suspect message stores.  Recipients can also choose to 
JdeBP> delegate the decision about whom they will pull mail from, 
JdeBP> to vetting services.

ITL> This is not different from SMTP plus RBL and similar systems.

It's certainly similar in concept, although it _is_ different.  For one thing,
in the SMTP case one is blacklisting clients, whereas in the IM2000 case one
is blacklisting servers.  For another, in the SMTP case blacklisting only
takes effect _after_ some network traffic has occurred, whereas in the IM2000
case blacklisting prevents _any_ network traffic from occurring.  

However, you are changing your question.  Your question was not how this was
different to SMTP.  It was:

	ILT> Why can't the spammer set up a zombie outgoing mail 
	ILT> store on a hacked system, [...] ?

The aforegiven shows that this is pointless because of the fact that the
ostracism mechanisms in IM2000 can be easily augmented by information-sharing
systems.

JdeBP> Third: A message store is a server, whereas an SMTP Relay
JdeBP> puppet is a client.  [...]

ILT> This is a good point.  I'll note that I personally run my 
ILT> own web/FTP/SMTP servers on my personal systems, but I 
ILT> admit that that is unusual these days.

It's also not relevant.  You were talking about hijacked machines.  If your
machines were hijacked, and then modified to provide an extra service that you
didn't intend to provide, then the same solutions apply whatever that extra
service is and whatever services you may currently run.  

JdeBP> (Think about it this way, if you like:  A hijacker can _right
JdeBP> now_ set up a web server on such a hijacked machine, 
JdeBP> publishing web pages of the hijacker's choosing.  Yet we don't
JdeBP> hear about an "unsolicited bulk web page" problem.)

ILT> You may not have heard about it, but I have.  

No you haven't.  The situation that you describe (apparently thinking that I
wasn't aware of it, even though you simply repeated what I actually wrote)
isn't an "unsolicited bulk web page" problem, and isn't described as such. 
People don't complain of "unsolicited" web pages being sent to them in "bulk"
from such servers, because that's simply not what happens.  (The same would be
true for hijacked machines running IM2000 message stores.)  Whereas people
_do_ complain of "unsolicited bulk mail" sent from hijacked machines running
SMTP Relay puppets.