Re: Edited Mail and Resent Headers

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.imc.org [mailto:owner-ietf-
>> smtp <at> mail.imc.org] On Behalf Of Hector Santos
>> Sent: Monday, May 17, 2010 7:14 PM
>> To: ietf-smtp <at> imc.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.
> 
> 
>