[Top] [All Lists]

Re: Edited Mail and Resent Headers

2010-05-21 19:32:51

Peter J. Holzer wrote:

On 2010-05-20 16:08:35 -0400, Hector Santos wrote:
The issue is based on the growing or rebirth of FORUMS that are gated by NNTP and exposed as newsgroups and the online software allow uses to correct/alter their mail (at any time), and the implementation does not create a new "message id" that would transforms to a new export by the NNTP gateway.

So I was thinking that maybe it (Resent-*) could be used here. It doesn't since the specs "implies" the old Message-ID remains the same and the Resent-Message-ID get the new one.

The old X.400 "Supersedes" was considered as a possibility to handle it but I am now considering a new proposal that addresses authenticated backend/mua interfacing, less than an IMAP but more than we have now for NNTP/POP3.

I don't know why you throw NNTP and POP3 together. They have rather
different models.

Both use a "Message Index/Number" concept in the listing and both use a GET by number concept.

Anyway, I assume that by "online edited mail" you mean a new version of
a forum/news article which should replace the old version. This is what
the "Supersedes" header is for: The new message gets a new message-ids
(In NNTP message-ids need to be unique - a new message which matches an
existing message-id simply won't be propagated because every newsserver
will assume that it already has the message) and reference the old
message in the Supersedes header. Servers and/or clients are supposed to
remove/hide superseded messages.

Right, keep in mind that the backend is not RFC 5322 ready. So there is a transformation process.

The backend has its own "Message ID" construct and this is currently used for the transformation:

    5322.Message-ID  <--- backend.Message.ID

The backend offer users the ability to "edit" their messages. In this implementation, the backend.Message.ID does not change. Its a simple body context replacement concept. The order is maintained, there is no DELETE OLD/CREATE NEW concept.

In this model, a NNTP gateway will not see this edited message message when it joins the group, i.e. the high mark does not change.

Continue below.

I don't see any relation to the Resent-* message headers.

Right. Nix that suggestion.

The overall issue is what suggestion could there be to allow both models to work well.

Of course, its all a function of the backend implementation to allow for this:

  - Keep a concept of same message online editing

  - Be compliant with RFC based mail reading to reflect the

What you are saying is the backend needs to able to pass (return) information to the gateway two pieces of information:


and the gateway can see this to perform the transformation:

   5322.Message-ID = backend.Message.ID;
   if (backend.Message.Previous.ID != 0) {
       5322.Supersedes = backend.Message.Previous.ID;

Again, obviously an implementation issue, but the online system will use a persistent backend.Message.ID, so probably it needs:

   backend.Message.RFC.ID   ; generated for edits only

where backend.Message.RFC.ID is only pertinent for gateways. Now the transformation would be:

   5322.Message-ID = backend.Message.ID;
   if (backend.Message.RFC.ID != 0) {
       5322.Message-ID = backend.Message.RFC.ID;
       5322.Supersedes = backend.Message.ID;

See the difference?

Overall, I am trying to see if there is a general model here that I can put on paper (and I-D) which offers backend vendors a simple way to maintain their desire for online editing of mail and still offer a way to interface with the traditional offline RFC based mail clients.


Hector Santos

<Prev in Thread] Current Thread [Next in Thread>