Re: SPF is harmful. Adopt it.

PJH> Where exactly is the difference between an unknown [SMTP MTS]
PJH> sending mail from an unknown mail address and an unknown 
PJH> IM2000 agent sending a reference to an unknown message store? 
PJH> In both cases the message can be be flagged as "suspicious".

Only in the IM2000 case can one definitely (by applying the IM2000 analogue of
RMX) rule out the possibility that the mail is from a "known" source. 
SMTP-based Internet mail is a "store and forward" system, and the possibility
exists in such a system that the mail is from a "known" source but has simply
travelled by an unknown route.  This is, after all, the architectural aspect
of SMTP-based Internet mail that has the fundamental conflict with SPF.

JdeBP> It's certainly similar in concept, although it _is_ 
JdeBP> different.  For one thing, in the SMTP case one is 
JdeBP> blacklisting clients, whereas in the IM2000 case one is
JdeBP> blacklisting servers.

PJH> How does that make difference?

You don't understand that blacklisting a server is different from blacklisting
a client ?

JdeBP> For another, in the SMTP case blacklisting only takes 
JdeBP> effect _after_ some network traffic has occurred, whereas 
JdeBP> in the IM2000 case blacklisting prevents _any_ network 
JdeBP> traffic from occurring.

PJH> You have that backwards. 

No, and your own example indeed disproves this assertion.  Read:

PJH> In SMTP, the client is backlisted by IP-address. The blacklisting
PJH> can take effect as soon as its IP address is known, which is as
PJH> soon as the first IP packet is received ([...]).

Here's where in the SMTP case blacklisting takes effect after network traffic
has occurred.

PJH> I don't see why the "ostracism mechanisms" in IM2000 should 
PJH> be more effective than RBLs are now.

Then go back and read all four points again.

PJH> It isn't perceived as "unsolicited bulk web pages" by users,
PJH> because they see it in their mailer, but in fact a lot of spam
PJH> looks very much like spam via IM2000 would look like:

No, it doesn't.  In the SMTP-based system the mail that you describe takes
advantage of poorly designed and written MUAs that will fetch external message
content automatically when displaying a message.  (I've already mentioned that
this is one reason that extending the GNKSoA from NUAs to MUAs would be a good
idea.)  In the non-equivalent IM2000 case that you are using as an analogy,
the user explicitly commands the recipient MUA to fetch the message that it
fetches.  

For a truly analogous case, one would have an IM2000 recipient MUA that was as
badly written as a POP3/IMAP MUA and that automatically fetched external
content when displaying messages.  But this is a generic MUA weakness and
nothing to do with IM2000.  With such badly designed MUAs, senders can send
messages that cause MUAs to take specific sender-controlled actions when those
messages are displayed.  This is a message content issue, not a message
transport issue.  As far as the message transport is concerned, the
distinctions between SMTP-based Internet mail and IM2000 Internet mail
covering how the message reached the MUA in the first place, before the MUA
decided to display and "execute" its contents, still apply.

PJH> In SMTP the simple fact that the mail is HTML and contains 
PJH> only a reference to an image is a good indicator that it is 
PJH> spam. But in IM2000, all messages contain only a reference 
PJH> to the message, so that distinction is lost.

Apples and oranges.  In the properly analogous IM2000 case, the notification
comprises a reference to a message, which _in turn_ contains HTML that
references an external image.  It is only the latter reference that weak and
badly designed MUAs follow automatically when displaying the message.

If you want to address this weakness, then the mail transport is irrelevant,
because *this is not a mail transport problem*.  It's a mail content problem. 
You address it by creating some GNKSoA:MUA standards and encouraging everyone
to hold MUAs up to them, as I mentioned in a previous message.

But we aren't discussing mail content here.  So coming back to the original
point, after that digression: An IM2000 message store on a hijacked machine is
no more a source of unsolicited bulk mail than a content HTTP server on the
same machine is a source of unsolicited bulk web pages.