Subject: Re: Edited Mail and Resent Headers
From: Hector Santos <[email-masked]>
To: [email-masked]
Cc: Peter J Holzer <[email-masked]>, ietf-smtpimcorg <[email-masked]>
Date: Sun, 23 May 2010 20:15:28 -0400
List-Id: <ietf-smtp.imc.org>

[email-masked] 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

From: [email-masked]
Cc: ietf-smtpimcorg <[email-masked]>
Date: Sun, 23 May 2010 12:55:41 -0700 (PDT)
Subject: Re: Edited Mail and Resent Headers
To: Peter J Holzer <[email-masked]>
Sender: [email-masked]

> ...

> 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.

? My MUA still has a "bounce" command to do
> this (and I prefer this over forwarding email in many cases).

The one in mine is called "resend", but the result is the same. I also agree
that it is preferable to forwarding in many cases.

				Ned

Date: Fri, 21 May 2010 20:14:30 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "[email-masked]" <[email-masked]>
Subject: Re: Edited Mail and Resent Headers
Sender: [email-masked]

Peter J. Holzer wrote:

> On 2010-05-20 16:08:35 -0400, Hector Santos wrote:
>> 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.
> 
> I don't know why you throw NNTP and POP3 together. They have rather
> different models. 

Both use a "Message Index/Number" concept in the listing and both use 
a  GET by number concept.

> Anyway, I assume that by "online edited mail" you mean a new version of
> a forum/news article which should replace the old version. This is what
> the "Supersedes" header is for: The new message gets a new message-ids
> (In NNTP message-ids need to be unique - a new message which matches an
> existing message-id simply won't be propagated because every newsserver
> will assume that it already has the message) and reference the old
> message in the Supersedes header. Servers and/or clients are supposed to
> remove/hide superseded messages.

Right, keep in mind that the backend is not RFC 5322 ready. So there 
is a transformation process.

The backend has its own "Message ID" construct and this is currently 
used for the transformation:

     5322.Message-ID  <--- backend.Message.ID

The backend offer users the ability to "edit" their messages.  In this 
  implementation, the backend.Message.ID does not change. Its a simple 
body context replacement concept.  The order is maintained, there is 
no DELETE OLD/CREATE NEW concept.

In this model, a NNTP gateway will not see this edited message message 
when it joins the group, i.e. the high mark does not change.

Continue below.

> I don't see any relation to the Resent-* message headers. 

Right. Nix that suggestion.

The overall issue is what suggestion could there be to allow both 
models to work well.

Of course, its all a function of the backend implementation to allow 
for this:

   - Keep a concept of same message online editing

   - Be compliant with RFC based mail reading to reflect the
     change.

What you are saying is the backend needs to able to pass (return) 
information to the gateway two pieces of information:

    backend.Message.ID
    backend.Message.Previous.ID

and the gateway can see this to perform the transformation:

    5322.Message-ID = backend.Message.ID;
    if (backend.Message.Previous.ID != 0) {
        5322.Supersedes = backend.Message.Previous.ID;
    }

Again, obviously an implementation issue, but the online system will 
use a persistent backend.Message.ID, so probably it needs:

    backend.Message.ID
    backend.Message.RFC.ID   ; generated for edits only

where backend.Message.RFC.ID is only pertinent for gateways.  Now the 
transformation would be:

    5322.Message-ID = backend.Message.ID;
    if (backend.Message.RFC.ID != 0) {
        5322.Message-ID = backend.Message.RFC.ID;
        5322.Supersedes = backend.Message.ID;
    }

See the difference?

Overall, I am trying to see if there is a general model here that I 
can put on paper (and I-D) which offers backend vendors a simple way 
to maintain their desire for online editing of mail and still offer a 
way to interface with the traditional offline RFC based mail clients.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Fri, 21 May 2010 20:32:05 +0200
From: "Peter J. Holzer" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Edited Mail and Resent Headers
Mail-Followup-To: "[email-masked]" <[email-masked]>
Sender: [email-masked]

--u5E4XgoOPWr4PD9E
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2010-05-20 16:08:35 -0400, Hector Santos wrote:
> The issue is based on the growing or rebirth of FORUMS that are gated by=
=20
> NNTP and exposed as newsgroups and the online software allow uses to=20
> correct/alter their mail (at any time), and the implementation does not=
=20
> create a new "message id" that would transforms to a new export by the=20
> NNTP gateway.
>
> So I was thinking that maybe it (Resent-*) could be used here. It =20
> doesn't since the specs "implies" the old Message-ID remains the same =20
> and the Resent-Message-ID get the new one.
>
> The old X.400 "Supersedes" was considered as a possibility to handle it=
=20
> but I am now considering a new proposal that addresses authenticated=20
> backend/mua interfacing, less than an IMAP but more than we have now for=
=20
> NNTP/POP3.

I don't know why you throw NNTP and POP3 together. They have rather
different models.=20

Anyway, I assume that by "online edited mail" you mean a new version of
a forum/news article which should replace the old version. This is what
the "Supersedes" header is for: The new message gets a new message-ids
(In NNTP message-ids need to be unique - a new message which matches an
existing message-id simply won't be propagated because every newsserver
will assume that it already has the message) and reference the old
message in the Supersedes header. Servers and/or clients are supposed to
remove/hide superseded messages.

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. My MUA still has a "bounce" command to do
this (and I prefer this over forwarding email in many cases).

	hp

--=20
   _  | Peter J. Holzer    | Openmoko has already embedded
|_|_) | Sysadmin WSR       | voting system.
| |   | [email-masked]         | Named "If you want it -- write it"
__/   | http://www.hjp.at/ |  -- Ilja O. on [email-masked]

--u5E4XgoOPWr4PD9E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

--u5E4XgoOPWr4PD9E--

Date: Thu, 20 May 2010 16:08:35 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: "[email-masked]" <[email-masked]>
Subject: Re: Edited Mail and Resent Headers
Sender: [email-masked]

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

Date: Tue, 18 May 2010 09:46:34 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Edited Mail and Resent Headers
Cc: "Murray S. Kucherawy" <[email-masked]>, Hector Santos <[email-masked]>
Organization: http://arnt.gulbrandsen.priv.no
Sender: [email-masked]

Murray S. Kucherawy quotes Hector Santos:
>> I am trying to determine if Resent Headers, in particular the 
>> Resent-Message-ID applies
>>  ...
>>
>>  What are you thoughts about this?
>
> I don't know exactly what you mean by "applies" here.

Neither do I... but I'll opine anyway.

Resent-* is dying or dead; so much new software doesn't look at it that 
Resent-* doesn't really "apply" to anything any more.

This isn't just about ignorant software. If you write an IMAP client in 
a way that will make all the IMAP-heads smile at you, that client is 
almost sure to ignore Resent-* (because IMAP's FETCH BODYSTRUCTURE 
ignores it).

Hm. Do any well-known MUAs take Resent-Message-Id into consideration 
when threading? I don't know, but I confess I haven't looked. I know 
some that don't.

Arnt

From: "Murray S. Kucherawy" <[email-masked]>
To: Hector Santos <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 17 May 2010 22:00:53 -0700
Subject: RE: Edited Mail and Resent Headers
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Hector Santos
> Sent: Monday, May 17, 2010 7:14 PM
> To: [email-masked]
> 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.

Date: Mon, 17 May 2010 22:13:41 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
Subject: Edited Mail and Resent Headers
Sender: [email-masked]

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?

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Fri, 14 May 2010 17:15:42 -0400
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: [email-masked]
Subject: Resent Headers and Online Mail Forums
Sender: [email-masked]

Are resent headers useful for situations where original postings of 
mail are edited by the original poster and the "edited" mail is 
resent?  In particular is how it relates to either a original and new 
Message-ID?

This was an old question for me that I put aside for backend mail 
forum system that has a NNTP portal or Mailing List gateway.

Now that Microsoft is abandoning their Microsoft.* newsgroups and 
shifting users toward their online forum system where "editing" of 
mail is allowed, the old question of whether it constitutes a new 
message thus a new reintroduction into a NNTP gateway made available 
for the online forums is the proper way to handle this.

-- 
Sincerely

Hector Santos
http://www.santronics.com

Date: Wed, 05 May 2010 11:09:14 +0100
From: Douglas Otis <[email-masked]>
To: [email-masked]
CC: Dave CROCKER <[email-masked]>, Murray Kucherawy <[email-masked]>, J D Falk <[email-masked]>, SMTP Interest Group <[email-masked]>, Tony Hansen <[email-masked]>
Subject: Re: Fwd: [ietf-dkim] ADSP discardable & discussion lists (was Re: Wrong Discussion - was Why mailing lists should strip DKIM signatures)
Sender: [email-masked]

On 5/4/10 12:21 AM, Dave CROCKER wrote:
>  On Apr 30, 2010, at 3:10 PM, Steve Atkins wrote:
>
> > If a mailing list were to simply reject all submissions from
> > senders who are publishing ADSP discardable that would ensure that
> > their wishes were not violated. And it seems to comply with the
> > spirit of ADSP discardable more than the riskier suggestions.
>
>  I believe that is the exact consensus conclusion we came to when
>  discussing ADSP discardable the first time.

How should ADSP "all" be handled, and how does "all" differ from that of 
"discardable"?
IMHO, the difference relates to whether a DSN might be generated, and 
should not otherwise cause differences in handling.

For DKIM to offer better protection, having a means to authorize 
third-party services when they might damage a signature could overcome 
the down side of offering a policy that might cause messages to be 
otherwise lost.

-Doug

Date: Mon, 03 May 2010 16:21:33 -0700
From: Dave CROCKER <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Murray Kucherawy <[email-masked]>
CC: J D Falk <[email-masked]>, SMTP Interest Group <[email-masked]>, Tony Hansen <[email-masked]>
Subject: Fwd: [ietf-dkim] ADSP discardable & discussion lists (was Re: Wrong Discussion - was Why mailing lists should strip DKIM signatures)
Sender: [email-masked]

This should probably be noted in the dkim/discussion list draft.

d/

-------- Original Message --------
Subject: [ietf-dkim] ADSP discardable & discussion lists (was Re: Wrong 
Discussion - was Why mailing lists should strip DKIM signatures)
Date: Mon, 3 May 2010 10:27:57 -0600
From: J.D. Falk <[email-masked]>
To: IETF-DKIM WG <[email-masked]>

On Apr 30, 2010, at 3:10 PM, Steve Atkins wrote:

> If a mailing list were to simply reject all submissions from senders
> who are publishing ADSP discardable that would ensure that their
> wishes were not violated. And it seems to comply with the spirit of
> ADSP discardable more than the riskier suggestions.

I believe that is the exact consensus conclusion we came to when discussing ADSP 
discardable the first time.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net