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.
Background:
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.
http://groups.google.com/group/microsoft.public.win32.programmer.kernel/msg/6bd19731560f6065
To smooth the migration a MS NNTP Bridge was developed to provide a
NNTP gateway to the MS Forums.
https://connect.microsoft.com/MicrosoftForums
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. :)
--
Sincerely
Hector Santos
http://www.santronics.com
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.