[Top] [All Lists]

Re: Edited Mail and Resent Headers

2010-05-20 15:25:46

Murray, Arnt,

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.


Microsoft will be turning off their 15 year old Microsoft Newsgroup NNTP servers and turning off microsoft.* newgroups. (Don't ask about the usenet rmgroups "control" fiasco that is going on).

Its happening starting June 1 and by October 1 they will be gone to be replaced by the currently Web-Based MS Forums.

To smooth the migration a MS NNTP Bridge was developed to provide a NNTP gateway to the MS Forums.

Beside some NNTP related protocol bugs, including not having a domain in the Message-ID, it works reasonable well.

Recently a beta tester pointed out an issue of online edited mail not getting exported hence offline users never see the "update." There was a design discussion on how address this given both sides of the mail model.

For our particular Mail framework with online and offline portals, we create a new message when online user edit mail, so a new message is seen and if its a networked forum, a new RFC message is goes back to the mail stream.

I was pushing that MS can do both and still provide an online "illusion" that the mail was replaced and not new added to the end of their mail storage and mail listing display. But the gateway will be able to pick it the new edited mail as a new article.

I personally think this will be a growing design requirment for mail vendors as we move back to online mail operations (or at least that is a direction we feel and see) and still need to offer some offline emulation of online sessions. Microsoft Live Mail nntp client has "more knowledge" about its interface with the backend.

Obviously, there are sensitives issue here with the offline MUA/USER having its own set of rules, security concerns and it will be sensitive issue for the backend try/force a deletion and replacement of mail on the user side using some additional "Replacement" RFC header.

Yes, I even suggested that they consider IMAP to better interface the two sides.

Anyway thats the skinny. :)


Hector Santos

Murray S. Kucherawy wrote:

-----Original Message-----
From: owner-ietf-smtp(_at_)mail(_dot_)imc(_dot_)org [mailto:owner-ietf-
smtp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Hector Santos
Sent: Monday, May 17, 2010 7:14 PM
To: ietf-smtp(_at_)imc(_dot_)org
Subject: Edited Mail and Resent Headers

I am trying to determine if Resent Headers, in particular the
Resent-Message-ID applies in cases the original message content is
altered (i.e, a user corrected his online message) and the mail is
re-introduced into the mail stream.

What are you thoughts about this?

I don't know exactly what you mean by "applies" here.

Here's my read on it:

Section 3.6.6 of RFC5322 says the use of any Resent-*: header field is a 
SHOULD.  That language isn't strong enough to say that a re-mailer of some 
kind, whether or not it alters the content, that doesn't also add a 
Resent-Message-ID: field is in violation of that RFC.

Even Section 3.6.4, which defines Message-ID:, doesn't specifically say that an 
altered form MUST receive a new Message-ID:.  It's clear that this is the 
intent, but there's nothing normative about it, so a remailer that doesn't 
issue a new Message-ID: is also not in violation of that RFC.

So since the language is soft, I'd say it always applies, but an agent that 
chooses not to follow that text isn't actually violating anything.

On the flipside, an agent that re-sends a message that has (or hasn't) been 
altered is free to decide whether or not to add a Resent-Message-Id field, so 
its presence (or absence) doesn't tell you definitively whether or not there's 
been an alteration enroute.

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