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?
Thanks
--
Sincerely
Hector Santos
http://www.santronics.com