Re: SPF is harmful. Adopt it.

>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.

SMTP being "store and forward" is orthagonal to whether a recipient
can disambiguate a hijacked machine versus a legitimate MTS, AFAICT.

In particular, an IM2000 recipient will need some way to be sure that
the outgoing message store is not itself running on a hijacked
machine, or is not subject to hijacked client machines injecting UBM
into it.

Better, IM2000 recipients will at least know the outgoing message
stores (assuming relaying isn't involved) have to be kept up and
running to continue serving messages for them to read, which assures
some level of commitment.

Worse, IM2000 recipients will also know their legitimate incoming
email might be lost or temporarily unreadable if it happens to be
hosted on an outgoing message store that has, since the legitimate
email was sent, become hijacked, decommissioned, whatever -- i.e.  if
that "some level of commitment" turns out to not have been quite
enough to maintain the integrity and availability of that outgoing
mail store.

Methinks IM2000 will quickly (before or shortly after deployment) need
a protocol by which outgoing mail stores can agree to transfer
responsibility for stored emails, along with protocols by which
recipient agents can be notified of such transfers.

Otherwise, it might be really, really hard to decommission an outgoing
mail store.

Of course, the problem of decommission an *incoming* mail notification
store remains as with SMTP (in which the incoming mail *message* store
has to be properly decommissioned).

But that's an easier problem to solve, since there aren't really
"dangling pointers" left to *incoming* mail stores as there will be to
*outgoing* mail stores.

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