Re: waiting on message notifications

JW> I would want my MUA to wait a certain amount of time (maybe 2 
JW> or 6 hours) before acknowledging (to the sending message store)
JW> notifications from servers it does not recognize. 

That's between you and your MUA.  Silencing notifications is something 
that _you_, as the recipient using your recipient MUA, trigger (as 
part of reading, transferring, or refusing a "new" message).

Read the case study of Lucy reading her mail.  Notice the various places where
notifications are silenced.

You can, if you so choose, create and use a recipient MUA that prevents you
from reading, transferring, or refusing any messages for 6 hours from the
arrival dates of their notifications, in order to let the effects of any
blacklist modifications made by other people kick in.  But that's a design
issue for your particular recipient MUA rather than an issue for IM2000 /per
se/.

JW> This way when a spammer sends out a deluge of notifications (I
JW> imagine a server could send out at least millions of these per
JW> minute) the people who chose short (or no) delay times will 
JW> flag it and nobody after that will download it.
JW> I would like my MUA to have a command to report the current
JW> message as spam to the same black list that it uses to check
JW> notifications.

Coöperative mass ostracism can be arranged in several ways.  This is one
possible way.  More complex variants of this scheme would deal with how well
you trusted such reports made by other people.  

Another entirely different (and a lot more anti-social) notification
processing policy would be to have a "club members only" system where all
notifications except those referencing an agreed whitelist of "known" message
stores were discarded.

The basic mechanism can support a range of different systems.

JW> Here's a half baked idea: Perhaps it would be separate from 
JW> IM2000 altogether, or perhaps some IM2000 inbox hosting 
JW> companies would create a black list based on the filters of 
JW> it's customers (with their permission of course.) 

Notification processing in essence involves three sets of rules:

   * Rules imposed by the recipient notification agent on behalf of its
owner.  These would usually be global to all recipients buying their services
there.  For example:  A recipient notification agent owner may make it a
selling point of its recipient notification agent service that it
automatically discards notifications based upon the say-so of a "well known"
message store ratings service company (a new area of business for Net Nanny,
say).

   * Rules imposed by the recipient notification agent on behalf of the
individual recipient.  A recipient could upload (via a RNAQP extension) a set
of rules to the recipient notification agent which would be automatically
applied by the notification agent to any notifications for that recipient. 
For example:  A recipient could specify that all notifications referencing the
"hotmail.com." message store were to be discarded.

   * Rules imposed by the recipient MUA on behalf of the recipient.  The
recipient MUA can of course do all sorts of things to the list of
notifications once it has retrieved them from the recipient notification
agent.  (One example that I mentioned before is the highlighting of the
notifications from "known" message stores that the recipient has designated.)

Only the second one involves IM2000 proper, and even then can be viewed as a
protocol extension rather than as a "core" part of RNAQP.  (Some unanswered
questions that you might like to tackle:  What would such a ruleset look like
?  Would it involve a scoring system with a set acceptance threshold ?  Would
it be a straight "Accept/Reject" list where the first entry that matched
applied ?  Would it be something else entirely ?)

Of course, the second one can also be viewed as a mere optimisation of the
third one, pushing a limited subset of the notification processing
capabilities of recipient MUAs into recipient notification agents.  Its
primary beneficiaries are the recipient notification agents themselves, of
course, as it allows them to immediately discard notifications that they know
to be unwanted.

JW> If this is a good idea, perhaps there should be a distinction 
JW> in the IM2000 protocol between telling your notification agent 
JW> to ignore messages, and telling it to ignore it because it's 
JW> spam.

I'm not convinced that anything need be added to RNAQP to support this
difference.  A possibly better approach would involve a separate "talking to
ratings service" protocol.  This would, of course, be outside of the IM2000
system proper.  How they communicated would be a matter entirely between one's
recipient MUA and the ratings service.  And I suspect that ratings would
generally be applied at the levels of originator accounts or message stores,
rather than at the levels of individual messages, given that the security
requirements of _desirable_ mail require it to be difficult for anyone but
message stores to determine the meanings of message identifiers.  Individual
messages would thus merely be counted as contributions towards an accumulated
ratings score for an originator account or a message store.