General principle
- The client (MUA) request a _Message Thread ID_
- The server (eventually) creates a new unique one and hands it over
to the client.
- The client _adds_ one or more Messages to the Message Thread
- The server (eventually) stores each Message and if it does so, it
returns the _Message ID_.
- The client tells the server, that it is done with the Message Block.
From this point on, it is the servers responsibility to notify the
recipients of the message(s).
- A follow up or reply is posted to a server by entering the above algorithm
at stage 3).
- The messages contents can convey any additional information higher
level tools like receiving MUA's, Messaging Channels, Mailing List
Managers, etc. would want, either in codification or in structure:
To Address, >From Address, real Name(s), Subject, Mime-type.
- The thread/block model allows to provide for multipart message mecanisms
as well as for following replies and forming discussion threads on
mailing or news lists, with one simple mecanism.
- Poster requested deletion of messages from a Message Thread could
be a useful extension, else messages are deleted by the server once
expired, retrieved or garbage collected.
- It may be required by the server, that a poster either creates a new
Message Thread, or is recipient or poster of an existing one to be
allowed to _add_ messages to it.
- A consistency check can assert that the poster of all messages in
a block is the same.
- The poster generated secuence numbers have to be monotonic, either
timestamps or a simple counter value.
- The usefulness of multiple poster identities per message would have
to be discussed with detailed: Does it allow spamming via replies
to all posters of a forged message? Does it facilitate Group Ware
Aplications by shortcut mailing list mecanisms?
- Notification of `"new`" messages need not convey the
individual Message ID's. Let us suppose, that the notification conveys
the Message Thread ID. Let us suppose that the server hands over to
a _collector_, autenticated as zero or more of the Recipients the
message id's of the messages directed to each individual Recipient.
The collector then decides which messages to retreive whole or partially,
to make further message processing decisions, based on the contents.
- It has to be able for a _collector_ to scan also for `"old`"
messages, as is the case with mailing lists.
- If a Recipient is a discussion list (a programm, or `"agent`"),
it may convert a message notification from a (list) poster into a
message pointer, which is posted as new message on the list server,
with all subscribed members as Recipients. - this applies to what
is called an _active notification_ list.
- All subscribed Recipients receive a notification, the message pointer
enables a mecanism, to retreive the original message from the original
posters' server, on behalf of the list-managers Recipient ID.
- So the posted message has not be copied over to a remote mailing-list
server.
- The one-level indirection only rule avoids loops, and maintains the
`"originator takes costs`" filosofy.
- If it is a new-like list, the message expires on the posters server.
- An archived list copies and stores the original message on the list
server.
- Of course, a `"spammer`" can forge a `"received`"
Email from an inocent victim, which (s)he then forwards as pointer
to millions of `"subscribed`" Recipients, which in
turn hammer the originating server down. To acchive this, the `"spammer`"
first has to convince the originating server to be the `"victim`"
to be able to post to that server. Anyway, the one level indirections
reveals inmediatly all participants.
Jorge.Lehner@gmx.net
