Re: Inexpensive anti-spamware/anti-verminware tactic

>Jonathan de Boyne Pollard <[email protected]> wrote:
>> JR> So recipients will find messages randomly disappearing 
>> JR> from their inboxes. 
>> 
>> Another mischaracterisation.  It's not random at all.  It's under the
>> originator's (and the mail store owner's) control.
>
>Which makes it, from the recipient's point of view, random, since they
>have no way of knowing what settings the originator is using, and
>different originators will have different settings.

More precisely, it makes the disappearance of messages from in-boxes
*arbitrary*, not *random*.

Most recipients won't know the difference, of course.  The question
is, will this property, inherent to relying on pull-based email
delivery, make IM2000 a good idea that never flies?  (That is, will
widespread worry about such arbitrary disappearances cause most IM2000
users to turn on local caching of most incoming messages anyway,
nullifying the distinct advantage of pull-style delivery?)

>> JR> ISP customers will be billed extra for storage that 
>> JR> is not under their control and that they can do nothing 
>> JR> about. 
>> 
>> Another straw man that bears no resemblance to the actual system being
>> discussed.
>
>I identify a huge flaw in the proposed system and you are unable to
>explain why it's not correct. Interesting.

It's not correct because ISP customers *can* control that storage, by
canceling outgoing messages, thus deleting them from their portion of
the outgoing message store.

Just as IM2000 recipients will (via MUAs) necessarily have a wide
range of facilities via which to interact with incoming messages,
*senders* will have a similar range of facilities, among which will
include:

  -  Monitoring status of each outgoing message (has it been cached,
     when, how often, etc.)

  -  Canceling outgoing message (with or without notifying its
     recipient(s))

  -  Scheduling cancelation of outgoing message (so recipients are
     notified they must decide "soon" whether to save it locally),
     either when originating the message or subsequently

  -  Transferring outgoing message to another message store (which
     requires notifying recipients via a distinct protocol)

  -  Being told by originator MUAs that there are certain patterns
     to long-unpinned messages in outgoing message stores, so
     senders can decide whether to mark certain recipients as
     "bad netizens" for not unpinning messages soon enough

And some nasty originator MUAs (spamware and vermin) might also
include:

  -  Substituting a new message for a message already in the store

Recipients can combat that by insisting (perhaps by making it inherent
to IM2000's design, at least optional but cleanly so) that message
notifications contain one or more hash-style signatures (SHA1, MD5,
whatever) for the message contents.

Then, when any agent acting on behalf of a recipient (such as a local
proxy cache) retrieved the message, it would compare the signature
against the advertised signature, and if the signatures disagreed, the
message notification (as well as the message) would be discarded, and
the outgoing message store possibly listed as "suspicious" due to
having signature problems.

Note that JdBP's IM2000 web pages don't really discuss several of the
six facilities for senders, described above, but there's nothing about
his IM2000 architecture and design proposal that bars such facilities
being offered, though two of them (scheduling cancelation of and
transferring outgoing messages) require, I think, accommodations in
certain of the IM2000 protocols he proposes.

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