[Top] [All Lists]

Re: Edited Mail and Resent Headers

2010-05-23 19:30:22

ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:


I don't see any relation to the Resent-* message headers. These were
intended for messages which were sent again (possibly by a different
sender) essentially unchanged.

This is my take on resent- as well.

Yes, that is clearly the expectation and semantics as I read them. I won't apply here.

I brought it up because I think it is not just an exclusive MS Forum/NNTP bridge issue. We had the same issue and the only real solution was to do a delete/create new for an edit mail concept to accommodate the offline mail readers or mail distribution to see the change.

I'm outlining an I-D for backend (non-RFC storage) mail forum software vendors on engineering considerations to help them better support RFC based transformation, in particular when it comes to online edited mail.

I have not done the research to see what MUA's support Supersedes, but overall would you think "Supersedes" header is sufficient here?

If so, it means the the backend end will need to have a "change id" concept that is only for RFC 5322 based gateways if it wishes to keep persistent internal message id for mail editing. So during the transformation:

  5322.Message-ID = Backend.Message.ID;

  // was this message edited?

  if (Backend.Message.ChangeID != "") {
   5322.Message-ID = Backend.Message.ChangeID;
   5322.Supersedes = Backend.Message.ID;

Does that make sense Ned?



Hector Santos

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