Subject: Re: SUMMARY: Limiting msg-id generate syntax
From: Frank Ellermann <[email-masked]>
To: [email-masked]
Date: Fri, 11 May 2007 11:14:23 +0200
List-Id: <ietf-822.imc.org>

Pete Resnick wrote:

> Define the left hand side of the "@" in msg-id to be
> (dot-atom-text / ob-id-left)

Good

> Leave the right hand side of msg-id as it is
> (dot-atom-text / no-fold-literal / obs-id-right)

With a new no-fold-literal adopted from USEFOR.

> RECOMMEND (or should it be REQUIRE?) that the right
> hand side be a domain identifier (either domain name
> or domain literal)

I'd like REQUIRE with an additional "SHOULD be a name"
reflecting the RFC 822 rule:

| THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED

> I'd prefer to leave the ABNF of domain-literal the way
> it is and limit in the text.

Not good enough for copy and paste into other drafts.
The "canonical" no-fold-literal syntax is quite simple:

| no-fold-literal =  "[" *( mdtext / "\[" / "\]" / "\\" ) "]"

| mdtext          =  %d33-61 /        ; The rest of the US-ASCII
|                    %d63-90 /        ; characters not including
|                    %d94-126         ; ">", "[", "]", or "\"

In essence that says "don't use quoted-pair unless you
must (and that's never the case for IPv4 or IPv6), and
stay away from '>', WSP, or NO-WS-CTL".

I'd prefer it if you also remove '<' from the picture.

The '>' was only the minimal difference from RFC 2822
for USEFOR, nobody needs angle brackets within a domain
literal.  They'd require percent-encoding in news URIs.

> I'd also be inclined to *not* talk about case-sensitivity
> and comparisons since nowhere is it discussed in 2822.

For consistency you could copy the relevant text from
USEFOR, stupid UAs trying to "beautify" the right hand
side could screw up threading by references.

Frank

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Dropping unused features
Date: Tue, 8 May 2007 19:38:59 -0400
Sender: [email-masked]

On 2007-05-08, Arnt Gulbrandsen wrote:

> Hm. I reread 1602 now and can't find any text saying that 
> standards-track progression should drop unused features. Isn't there 
> any?

1602 has long been obsoleted by 2026 (October 1996).  Quoting 2026:

"  The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification.  In cases in which one or more options or features
   have not been demonstrated in at least two interoperable
   implementations, the specification may advance to the Draft Standard
   level only if those options or features are removed.
"

That (as worded) is quite a bit stronger than "should drop".  It's
more like "must drop".

If a feature is in fact unused, it's going to be awfully difficult to
find two implementations...  In theory, even if a feature is used by
only one implementation, it must be removed in order for the
specification to advance to Draft.  In practice, there is an abundant
supply of loopholes; for one thing, "feature" is not defined in 2026.

Date: Tue, 8 May 2007 15:37:10 -0600
From: Philip Guenther <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: SUMMARY: Limiting msg-id generate syntax
Sender: [email-masked]

On Tue, 8 May 2007, Arnt Gulbrandsen wrote:
...
>>> I'd also be inclined to *not* talk about case-sensitivity and comparisons 
>>> since nowhere is it discussed in 2822.
>
> Agree. I can't even think of a way to count what the running code does.

There are two places it matters: in the copying of message-ids for replies 
and in the implementation of threading algorithms.

If a MUA generating a reply were to try to 'clean up' the message-ids in 
the parent that use the obsolete syntax (because it wants its reply to 
match the generate syntax), then the MUA needs to only strip CFWS and 
tweak quoting and not get carried away and normalize case too.

On the threading side, well, draft-ietf-imapext-sort-18 says
                    Note: Message ID comparisons are case-sensitive.
so this issue is covered from that angle.  Actually testing threading 
implementations outside of IMAP would be laborious...

Philip Guenther

Date: Tue, 8 May 2007 15:25:31 -0600
From: Philip Guenther <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: ietf-822 <[email-masked]>
Subject: Re: SUMMARY: Limiting msg-id generate syntax
Sender: [email-masked]

On Mon, 7 May 2007, Pete Resnick wrote:
> So, scream now or forever hold your peace on the following:
>
> - Define the left hand side of the "@" in msg-id to be (dot-atom-text / 
> ob-id-left)
> - Leave the right hand side of msg-id as it is (dot-atom-text / 
> no-fold-literal / obs-id-right)
> - Leave the text to normatively RECOMMEND (or should it be REQUIRE?) that the 
> right hand side be a domain identifier (either domain name or domain literal)

Sounds good to me.

...
> I'd also be inclined to *not* talk about case-sensitivity and comparisons 
> since nowhere is it discussed in 2822.

Message-ids a required to be globally unique.  How can an implementor 
know that his generate-id algorithm is acceptable without knowing what the 
equality test is?  (Okay, that's a bit weak...)

The real issue for 2822 is actually in the copying of message-ids into the 
in-reply-to and references fields.  A MUA that forces id-right components 
to lower-case will break threading.  I guess the current text's 
description of how the reply's references and in-reply-to fields are 
generated is good enough, given that is says "copy the contents" and not 
"extract the ids and put them in the new field".

Probably unrelated to the above: MUAs have to accept messages with 
message-ids using the obsolete syntax, but if they follow the rules when 
generating a reply then the reply won't obey the generate syntax.

Philip Guenther

Date: Tue, 8 May 2007 15:23:21 -0500
To: Arnt Gulbrandsen <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: SUMMARY: Limiting msg-id generate syntax
Cc: [email-masked], [email-masked], Dave Crocker  <[email-masked]>
Sender: [email-masked]

On 5/8/07 at 9:58 PM +0200, Arnt Gulbrandsen wrote:

>Dave Crocker writes:
>>Are we sure that the proposed changes would not require re-cycling 
>>RFC2822 at Proposed Standard?
>
>Hm. I reread 1602 now and can't find any text saying that 
>standards-track progression should drop unused features. Isn't there 
>any?

RFC 2026, section 4.1.2:

    In cases in which one or more options or features
    have not been demonstrated in at least two interoperable
    implementations, the specification may advance to the Draft Standard
    level only if those options or features are removed.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated

Date: Tue, 8 May 2007 21:58:44 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: SUMMARY: Limiting msg-id generate syntax
Cc: Pete Resnick <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>
Sender: [email-masked]

Dave Crocker writes:
> Are we sure that the proposed changes would not require re-cycling 
> RFC2822 at Proposed Standard?

Hm. I reread 1602 now and can't find any text saying that 
standards-track progression should drop unused features. Isn't there 
any?

> d/
>
> Pete Resnick wrote:
>
>> There appears to be a good contingent that is willing to limit the 
>> generate syntax for message id's to dot-atoms on the left of the "@" 
>> and domain-name- or domain-literal- looking things on the right. 
>> This would not change the *interpret* (obs-) syntax which would 
>> still require interpreting quoted-strings on the left. So, scream 
>> now or forever hold your peace on the following:
>>
>> - Define the left hand side of the "@" in msg-id to be (dot-atom-text 
>> / ob-id-left)
>> - Leave the right hand side of msg-id as it is (dot-atom-text / 
>> no-fold-literal / obs-id-right)
>> - Leave the text to normatively RECOMMEND (or should it be REQUIRE?) 
>> that the right hand side be a domain identifier (either domain name 
>> or domain literal)

+1

I tend towards RECOMMEND. In a sample of 750,000 recent message-ids I 
found about 99.1% compliance, which is SHOULD-land IMO.

>> I'd prefer to leave the ABNF of domain-literal the way it is and 
>> limit in the text. We've already got examples of having to unlimit 
>> Received because of bugs in 2822 and so that fixes in 2821bis could 
>> be accommodated; I'd rather leave it to other documents to define 
>> what it is to be a valid "domain identifier." (Remember, you've got 
>> to interpret all of the mess anyway, so the only thing that putting 
>> it into the ABNF would do is reinforce the requirement in the text.)

No opinion.

>> I'd also be inclined to *not* talk about case-sensitivity and 
>> comparisons since nowhere is it discussed in 2822.

Agree. I can't even think of a way to count what the running code does.

Arnt

Date: Tue, 08 May 2007 11:27:01 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Pete Resnick <[email-masked]>
CC: ietf-822 <[email-masked]>, Lisa Dusseault <[email-masked]>, Chris Newman <[email-masked]>
Subject: Re: SUMMARY: Limiting msg-id generate syntax
Sender: [email-masked]

Pete Resnick wrote:
> 
> [Cc'ing our ADs just in case they didn't notice this.]
> 
> On 5/8/07 at 8:48 AM -0700, Dave Crocker wrote:
> 
>> Are we sure that the proposed changes would not require re-cycling 
>> RFC2822 at Proposed Standard?
> 
> I can't see why. The only real change here is to remove "no-fold-quote" 
> from the "allowed to generate" syntax for message ids. (Of course we 
> still require that they be interpreted.) I think this amounts to 
> "removing an unused/non-interoperable feature", which is a *desirable* 
> thing when moving to Draft.

ahh.  right.  merely dropping an unused construct.

i thought I was seeing suggestions for making real semantic changes.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

From: Russ Allbery <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: SUMMARY: Limiting msg-id generate syntax
Organization: The Eyrie
Date: Tue, 08 May 2007 10:51:18 -0700
Sender: [email-masked]

Pete Resnick <[email-masked]> writes:

> I can't see why. The only real change here is to remove "no-fold-quote"
> from the "allowed to generate" syntax for message ids. (Of course we
> still require that they be interpreted.) I think this amounts to
> "removing an unused/non-interoperable feature", which is a *desirable*
> thing when moving to Draft.

Wholeheartedly agreed.  I seriously doubt that anyone is actually
successfully using this feature in RFC 2822 now.  One just doesn't notice
because no one tries, and even if they do try, message ID matching
differences aren't particularly noticable in e-mail the way that they are
on Usenet.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

Date: Tue, 8 May 2007 12:22:02 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: SUMMARY: Limiting msg-id generate syntax
Cc: ietf-822 <[email-masked]>, Dave Crocker <[email-masked]>, Lisa Dusseault <[email-masked]>, Chris Newman <[email-masked]>
Sender: [email-masked]

[Cc'ing our ADs just in case they didn't notice this.]

On 5/8/07 at 8:48 AM -0700, Dave Crocker wrote:

>Are we sure that the proposed changes would not require re-cycling 
>RFC2822 at Proposed Standard?

I can't see why. The only real change here is to remove 
"no-fold-quote" from the "allowed to generate" syntax for message 
ids. (Of course we still require that they be interpreted.) I think 
this amounts to "removing an unused/non-interoperable feature", which 
is a *desirable* thing when moving to Draft.

>Pete Resnick wrote:
>>
>>There appears to be a good contingent that is willing to limit the 
>>generate syntax for message id's to dot-atoms on the left of the 
>>"@" and domain-name- or domain-literal- looking things on the 
>>right. This would not change the *interpret* (obs-) syntax which 
>>would still require interpreting quoted-strings on the left. So, 
>>scream now or forever hold your peace on the following:
>>
>>- Define the left hand side of the "@" in msg-id to be 
>>(dot-atom-text / ob-id-left)
>>- Leave the right hand side of msg-id as it is (dot-atom-text / 
>>no-fold-literal / obs-id-right)
>>- Leave the text to normatively RECOMMEND (or should it be 
>>REQUIRE?) that the right hand side be a domain identifier (either 
>>domain name or domain literal)
>>
>>I'd prefer to leave the ABNF of domain-literal the way it is and 
>>limit in the text. We've already got examples of having to unlimit 
>>Received because of bugs in 2822 and so that fixes in 2821bis could 
>>be accommodated; I'd rather leave it to other documents to define 
>>what it is to be a valid "domain identifier." (Remember, you've got 
>>to interpret all of the mess anyway, so the only thing that putting 
>>it into the ABNF would do is reinforce the requirement in the text.)
>>
>>I'd also be inclined to *not* talk about case-sensitivity and 
>>comparisons since nowhere is it discussed in 2822.
>>
>>pr
>
>--
>
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

To: [email-masked]
Xref: clerew local.mime:5022
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: SUMMARY: Limiting msg-id generate syntax
Date: Tue, 8 May 2007 11:32:46 GMT
Lines: 49
Sender: [email-masked]

In <p0630000ec26532b2d53d@[75.204.224.24]> Pete Resnick <[email-masked]> writes:

>- Define the left hand side of the "@" in msg-id to be (dot-atom-text 
>/ ob-id-left)
>- Leave the right hand side of msg-id as it is (dot-atom-text / 
>no-fold-literal / obs-id-right)
>- Leave the text to normatively RECOMMEND (or should it be REQUIRE?) 
>that the right hand side be a domain identifier (either domain name 
>or domain literal)

>I'd prefer to leave the ABNF of domain-literal the way it is and 
>limit in the text.

I'm not too happy with that. The only things that need removing are
redundant <quoted-pair>s (e.g "\a") and maybe NO-WS-CTLs. That is nothing
like the mess of trying to fix <no-fold-quote>s in ABNF, and in fact the
syntax in the USEFOR draft is all that you would need:

   no-fold-literal =  "[" *( mdtext / "\[" / "\]" / "\\" ) "]"

   mdtext          =  %d33-61 /        ; The rest of the US-ASCII
                      %d63-90 /        ; characters not including
                      %d94-126         ; ">", "[", "]", or "\"

OK, you would need to add an obs- bit to that.

>I'd also be inclined to *not* talk about case-sensitivity and 
>comparisons since nowhere is it discussed in 2822.

OK. You seem to have allowed <local-part>s to be case sensitive without
actually saying so, so the same would apply to <msg-id>s. The only slight
worry is that people might still try to argue that the stuff after the "@"
is a domain-name, and therefore case-insenitive. Yes, that argument is
wrong as RFC 2822 is written, but not so obviously wrong that people are
not going to try it. Perhaps some remark (not normative) that <mesg-id>s
have been so designed that equality between them is simply a matter of
octet-by-octet comparison.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Tue, 08 May 2007 08:48:37 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Pete Resnick <[email-masked]>
CC: ietf-822 <[email-masked]>
Subject: Re: SUMMARY: Limiting msg-id generate syntax
Sender: [email-masked]

Are we sure that the proposed changes would not require re-cycling RFC2822 at 
Proposed Standard?

d/

Pete Resnick wrote:
> 
> There appears to be a good contingent that is willing to limit the 
> generate syntax for message id's to dot-atoms on the left of the "@" and 
> domain-name- or domain-literal- looking things on the right. This would 
> not change the *interpret* (obs-) syntax which would still require 
> interpreting quoted-strings on the left. So, scream now or forever hold 
> your peace on the following:
> 
> - Define the left hand side of the "@" in msg-id to be (dot-atom-text / 
> ob-id-left)
> - Leave the right hand side of msg-id as it is (dot-atom-text / 
> no-fold-literal / obs-id-right)
> - Leave the text to normatively RECOMMEND (or should it be REQUIRE?) 
> that the right hand side be a domain identifier (either domain name or 
> domain literal)
> 
> I'd prefer to leave the ABNF of domain-literal the way it is and limit 
> in the text. We've already got examples of having to unlimit Received 
> because of bugs in 2822 and so that fixes in 2821bis could be 
> accommodated; I'd rather leave it to other documents to define what it 
> is to be a valid "domain identifier." (Remember, you've got to interpret 
> all of the mess anyway, so the only thing that putting it into the ABNF 
> would do is reinforce the requirement in the text.)
> 
> I'd also be inclined to *not* talk about case-sensitivity and 
> comparisons since nowhere is it discussed in 2822.
> 
> pr

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 7 May 2007 15:15:01 -0500
To: ietf-822 <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: SUMMARY: Limiting msg-id generate syntax
Sender: [email-masked]

There appears to be a good contingent that is willing to limit the 
generate syntax for message id's to dot-atoms on the left of the "@" 
and domain-name- or domain-literal- looking things on the right. This 
would not change the *interpret* (obs-) syntax which would still 
require interpreting quoted-strings on the left. So, scream now or 
forever hold your peace on the following:

- Define the left hand side of the "@" in msg-id to be (dot-atom-text 
/ ob-id-left)
- Leave the right hand side of msg-id as it is (dot-atom-text / 
no-fold-literal / obs-id-right)
- Leave the text to normatively RECOMMEND (or should it be REQUIRE?) 
that the right hand side be a domain identifier (either domain name 
or domain literal)

I'd prefer to leave the ABNF of domain-literal the way it is and 
limit in the text. We've already got examples of having to unlimit 
Received because of bugs in 2822 and so that fixes in 2821bis could 
be accommodated; I'd rather leave it to other documents to define 
what it is to be a valid "domain identifier." (Remember, you've got 
to interpret all of the mess anyway, so the only thing that putting 
it into the ABNF would do is reinforce the requirement in the text.)

I'd also be inclined to *not* talk about case-sensitivity and 
comparisons since nowhere is it discussed in 2822.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: Compatibility wit Netnews
Organization: The Eyrie
Date: Thu, 03 May 2007 12:51:59 -0700
Sender: [email-masked]

Charles Lindsey <[email-masked]> writes:
> Philip Guenther <[email-masked]> writes:

>> On Wed, 2 May 2007, Charles Lindsey wrote:
>> ...
>>> I should have added there that Netnews also expects to do all 
>>> [message-id] comparisons case-sensitively.

>> Ah, now there's something that should be added in 2822bis: a statement 
>> that although message-ids use a syntax related to the syntax for 
>> mailboxes, they must be handled as case-sensitive, even the "looks like a 
>> domain" right-hand side.

> +1

Agreed.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

To: [email-masked]
Xref: clerew local.mime:5019
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt)
Date: Thu, 3 May 2007 10:11:26 GMT
Lines: 24
Sender: [email-masked]

In <[email-masked]> Philip Guenther <[email-masked]> writes:

>On Wed, 2 May 2007, Charles Lindsey wrote:
>...
>> I should have added there that Netnews also expects to do all 
>> [message-id] comparisons case-sensitively.

>Ah, now there's something that should be added in 2822bis: a statement 
>that although message-ids use a syntax related to the syntax for 
>mailboxes, they must be handled as case-sensitive, even the "looks like a 
>domain" right-hand side.

+1

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

From: [email-masked]
Cc: ietf-822 <[email-masked]>
Date: Wed, 02 May 2007 21:44:23 -0700 (PDT)
Subject: Re: [2822upd] Resent-* MUSTard
To: Bruce Lilly <[email-masked]>
Sender: [email-masked]

> On 2007-05-02, Ned Freed wrote:

> > Bruce was talking about automatic agents

> I was referring to resending, without stating whether that was done by a
> person or an agent.  The only automatic part involved in that discussion
> was a vacation autoresponder acting on behalf of the recipient of the
> resent message, not the resender.

And I was referring to the fact that you were talking about automatic agents
and that it colored my response when it should not have. Nowhere did I say or
even imply that you were talking about automatic resending agents.

				Ned

From: [email-masked]
Cc: [email-masked]
Date: Wed, 02 May 2007 15:27:00 -0700 (PDT)
Subject: Re: [2822upd] Resent-* MUSTard
To: Bruce Lilly <[email-masked]>
Sender: [email-masked]

> On Tuesday 01 May 2007 20:12:47 [email-masked] wrote:

> > OK, so the logic here is that if you're going to break the rules, you should as
> > your second option fall back to behavior that doesn't cause quite as much
> > breakage?

> No. First, RFC 3834's SHOULD is more of a suggestion than a rule; "MUST"
> would be about as close as any RFC gets to specifying a rule.

SHOULDs are only supposed to be violated if there's a compelling reason to do
so. Whatever that reason is would presumably also determine what alternative
strategy makes sense and whether or not resent- fields should be honored.

>  I'll try again, in small steps:

> 1. There exist autoresponders that use the From (or Sender) field.

Yes, but this doesn't answer the question of whether they're doing it for
legitimate reasons or because they are broken. If they are broken they should
be fixed, if they are doing it for legitimate purposes I don't think we should
be trying to second guess their behavior unless we can come up with  some
fairly clear generalizations of how all this works I for one have never seen
before.

> 2. There may exist autoresponders that use Resent- versions (I
>    haven't looked for them, and I don't generally resend messages);
>    at least for the specific example given, these produce less
>    astonishment than the above.

Maybe, maybe not. It all depends on what the goal is.

> 3. Therefore, rather than a blanket "automatic processing should always
>    use From/Date/etc. rather than Resent- versions", it would be prudent
>    to carefully consider and document specific cases where
>    a) use of Resent- versions is preferable to non Resent- versions
>    b) vice-versa
>    c) neither should be used
>    d) depends on what the user wants

Guidelines for when to use resent-from versus from would first have to consider
when it is appropriate not to use the return-path. I am very skeptical that
reasonable guidelines for this can be constructed.

> 4. Ideally, the Resent- fields would be described in sufficient detail to
>    clarify these issues; 2822 is fairly good w.r.t. quantity, placement, and
>    syntax; semantics are described fairly well; who/what should produce,
>    modify, or consume the fields is lacking (see RFC 4249 for a list of the
>    types of things that implementers may find useful, resulting from a
>    discussion on this list a few years ago).

> > At the point where the redirection is done there isn't a return-path, only
> > an envelope. 2822bis does not and should not discuss envelope issues - that's
> > for 2821bis.
> [...]
> > It is *absolutely* the case that a return-path field should not be part of the
> > redirected message. The creation of the return-path is the job of the final
> > delivery agent.

> That seems to be based on a rather parochial assumption about message
> delivery architecture;  in many cases, mail arrives in a POP/IMAP/whatever
> mailbox at an ISP's server, where some agent has made "final" delivery,
> whereupon a user can access the message (complete with Return-Path
> field), and in so doing can redirect/retransmit to one or more mailboxes
> beyond the "final" delivery (hence the quotation marks).

The "parochial" assumption you refer to is one which when violated routinely
causes a wide variety of problems operationally. You'll have to forgive me for
not wanting to engage in tacti endorsement of problematic practices, parochial
though that viewpoint may be.

> > > 4. Security Considerations should mention the possibilities for abuse (e.g.
> > >    using the rules re. non-use of Resent- fields by "automated actions"
> > >    to disguise the source of spam, etc.)
> >
> > This I do agree with, although I'm not entirely clear what should be
> > said.

> "Lasciate ogne speranza"? :-/

As Pete has already pointed out "voi ch'intrate" includes a lot of legitimate
uses.

> > > Clear definitions may help greatly. E.g. 2822 is pretty clear that the
> > > author is specified by the From field; therefore Resent-From specifies
> > > something other than the author.  One area that needs clarification is the
> > > definition of "user", which should be consistent among the documents
> > > discussing applications of the message format.  2822 says w.r.t. Resent-
> > > fields "Resent fields are used to identify a message as having been
> > > reintroduced into the transport system by a user"; I know of at least one
> > > document that states that a mailing list exploder is a "user", which is
> > > probably inconsistent with 2822's intent regarding Resent- fields...
> >
> > I also have no problem with clarification of definitions, but specific
> > suggestions would be nice...

> The specific document alluded to uses "user" to include gateways and list
> expansion. I suspect that's not what is meant by the 2822 text above, but I
> cannot find a definition in 2822 of precisely what is meant there by "user".

> I would prefer to reserve "user" to refer to an end-point producer or recipient
> of messages, which may be a human, or might be some autonomous system.

> "User agent" would be an entity (typically software) operating on behalf of
> a user (q.v.) and possibly in interaction with same; such operations might
> include managing address books, ensuring proper syntax of generated
> messages, presentation of content (N.B. presentation might include
> text-to-speech), properly generating/extracting attachments, etc.

> Beyond those, we could define "gateway", possibly including distinctions
> among various types of gateways, and other terms as needed.  Evidently
> a better definition of resending seems to be needed...

That may be but after all the discussion of this in DRUMS I'm dubious as to
what can be done.

				Ned

From: Bruce Lilly <[email-masked]>
Reply-To: [email-masked]
Organization: Bruce Lilly
To: [email-masked]
Subject: Re: [2822upd] Resent-* MUSTard
Date: Wed, 2 May 2007 17:13:27 -0400
Sender: [email-masked]

On Tuesday 01 May 2007 20:12:47 [email-masked] wrote:

> OK, so the logic here is that if you're going to break the rules, you should as
> your second option fall back to behavior that doesn't cause quite as much
> breakage?

No. First, RFC 3834's SHOULD is more of a suggestion than a rule; "MUST"
would be about as close as any RFC gets to specifying a rule.

 I'll try again, in small steps:
1. There exist autoresponders that use the From (or Sender) field.
2. There may exist autoresponders that use Resent- versions (I
   haven't looked for them, and I don't generally resend messages);
   at least for the specific example given, these produce less
   astonishment than the above.
3. Therefore, rather than a blanket "automatic processing should always
   use From/Date/etc. rather than Resent- versions", it would be prudent
   to carefully consider and document specific cases where
   a) use of Resent- versions is preferable to non Resent- versions
   b) vice-versa
   c) neither should be used
   d) depends on what the user wants
4. Ideally, the Resent- fields would be described in sufficient detail to
   clarify these issues; 2822 is fairly good w.r.t. quantity, placement, and
   syntax; semantics are described fairly well; who/what should produce,
   modify, or consume the fields is lacking (see RFC 4249 for a list of the
   types of things that implementers may find useful, resulting from a
   discussion on this list a few years ago).

> At the point where the redirection is done there isn't a return-path, only
> an envelope. 2822bis does not and should not discuss envelope issues - that's
> for 2821bis.
[...] 
> It is *absolutely* the case that a return-path field should not be part of the
> redirected message. The creation of the return-path is the job of the final
> delivery agent.

That seems to be based on a rather parochial assumption about message
delivery architecture;  in many cases, mail arrives in a POP/IMAP/whatever
mailbox at an ISP's server, where some agent has made "final" delivery,
whereupon a user can access the message (complete with Return-Path
field), and in so doing can redirect/retransmit to one or more mailboxes
beyond the "final" delivery (hence the quotation marks).

> > 4. Security Considerations should mention the possibilities for abuse (e.g.
> >    using the rules re. non-use of Resent- fields by "automated actions"
> >    to disguise the source of spam, etc.)
> 
> This I do agree with, although I'm not entirely clear what should be
> said.

"Lasciate ogne speranza"? :-/

> > Clear definitions may help greatly. E.g. 2822 is pretty clear that the
> > author is specified by the From field; therefore Resent-From specifies
> > something other than the author.  One area that needs clarification is the
> > definition of "user", which should be consistent among the documents
> > discussing applications of the message format.  2822 says w.r.t. Resent-
> > fields "Resent fields are used to identify a message as having been
> > reintroduced into the transport system by a user"; I know of at least one
> > document that states that a mailing list exploder is a "user", which is
> > probably inconsistent with 2822's intent regarding Resent- fields...
> 
> I also have no problem with clarification of definitions, but specific
> suggestions would be nice...

The specific document alluded to uses "user" to include gateways and list
expansion. I suspect that's not what is meant by the 2822 text above, but I
cannot find a definition in 2822 of precisely what is meant there by "user".

I would prefer to reserve "user" to refer to an end-point producer or recipient
of messages, which may be a human, or might be some autonomous system.

"User agent" would be an entity (typically software) operating on behalf of
a user (q.v.) and possibly in interaction with same; such operations might
include managing address books, ensuring proper syntax of generated
messages, presentation of content (N.B. presentation might include
text-to-speech), properly generating/extracting attachments, etc.

Beyond those, we could define "gateway", possibly including distinctions
among various types of gateways, and other terms as needed.  Evidently
a better definition of resending seems to be needed...

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: <quoted-string>s in <msg-id>s
Date:  Wed, 02 May 2007 23:09:44 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 27
Sender: [email-masked]

Arnt Gulbrandsen wrote:

> Message-Id: <"28901 98/02/05
> 04:04*/c=no/admd=telemax/prmd=telenor/o=fou/ou=lillehammer/s=xxx/g=yyy/"@MHS>

> (All the messages from this gateway were from military institutions or
> badly managed state-owned telcos, so I assume someone on this list can
> guess which software this was.)

We have to look at the successor of Harald's "MIXER" spec. and check if
it needs that:  RFC 2156.  One example in 2156 uses no quoted string:

| Message-ID:
|  <562*/S=Eppenberger/OU=verw/O=switch/PRMD=SWITCH/ADMD=ARCOM/C=CH/@MHS>

Examples for the opposite direction (from 822 to X.400) use it, we can
probably ignore them:

| Message-ID: <"bells.cs.u.694:07.01.91.15.48.34"@cs.ucl.ac.uk>

| Message-ID: <"DLE/910207154840Z/000"@cs.ucl.ac.uk>

Frank

P.S. to Bruce,
yes, only looking at examples is bad, but I have to go to bed now... :-)

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Compatibility wit Netnews
Date:  Wed, 02 May 2007 22:54:43 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 13
Sender: [email-masked]

Charles Lindsey wrote:

> Removing <quoted-pair> from it would remove most of the problem, and
> defning a restricted version of <dtext> without NO-WS-CTL would do the
> rest (it might even be a Good Idea to remove NO-WS-CTL from all
> <dtext>s).

Yes, please.  This means no "[", "\", "]", or NO-WS-CTL inside of an
address literal, and as it happens nobody needs this for IPv4, IPv6. or
the "IPvFuture" specified in STD 66.

Frank

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: [2822upd] Resent-* MUSTard
Date: Wed, 2 May 2007 16:26:13 -0400
Sender: [email-masked]

On 2007-05-02, Pete Resnick wrote:

> It is perfectly 
> reasonable to resend post-delivery. In that case, you'll have 
> Resent-* fields prepended to the message which may already have a 
> Return-Path. It will get a new Return-Path when it is delivered to 
                  will -> may (Return-Path is optional per *822 (and
as previously noted, resending might not use SMTP))
> the mailbox in the Resent-To, and that will be the MAIL FROM of the 
> resender.
> 
> Maybe there's an argument for removing a Return-Path before 
> prepending the Resent-* fields, but that's a different discussion.

Sounds reasonable.  Maybe resending and the Resent- fields could be
moved to a separate document, which could more fully discuss the
issues relevant to resending (which transcends the message format per se).

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: [2822upd] Resent-* MUSTard
Date: Wed, 2 May 2007 16:16:07 -0400
Sender: [email-masked]

On 2007-05-02, Ned Freed wrote:

> Bruce was talking about automatic agents

I was referring to resending, without stating whether that was done by a
person or an agent.  The only automatic part involved in that discussion
was a vacation autoresponder acting on behalf of the recipient of the
resent message, not the resender.

Date: Wed, 2 May 2007 12:34:38 -0600
From: Philip Guenther <[email-masked]>
To: Charles Lindsey <[email-masked]>
cc: [email-masked]
Subject: Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt)
Sender: [email-masked]

On Wed, 2 May 2007, Charles Lindsey wrote:
...
> I should have added there that Netnews also expects to do all 
> [message-id] comparisons case-sensitively.

Ah, now there's something that should be added in 2822bis: a statement 
that although message-ids use a syntax related to the syntax for 
mailboxes, they must be handled as case-sensitive, even the "looks like a 
domain" right-hand side.

Philip Guenther

From: [email-masked]
Cc: [email-masked], Bruce Lilly <[email-masked]>, ietf-822 <[email-masked]>
Date: Wed, 02 May 2007 10:31:09 -0700 (PDT)
Subject: Re: [2822upd] Resent-* MUSTard
To: Pete Resnick <[email-masked]>
Sender: [email-masked]

> On 5/1/07 at 5:12 PM -0700, [email-masked] wrote:

> >  > 2. Which Return-Path (2821 issue resurfaces); 2822 says "No other fields
> >>     in the message are changed when resent fields are added", and taken at
> >>     face value, that includes Return-Path.
> >
> >At the point where the redirection is done there isn't a
> >return-path, only an envelope. 2822bis does not and should not
> >discuss envelope issues - that's for 2821bis.

> This is the one thing on which I disagree with Ned.

Actually, I don't think we disagree. Bruce was talking about automatic agents
and I somehow managed to conflate in my subsequent discussion of resending.

I do think that the further away you get from final delivery the less sense it
makes to have automatic resending agents. But I don't think there should be any
hard rules about this.

> It is perfectly 
> reasonable to resend post-delivery.

Absolutely. I do it myself all the time.

> In that case, you'll have
> Resent-* fields prepended to the message which may already have a
> Return-Path. It will get a new Return-Path when it is delivered to
> the mailbox in the Resent-To, and that will be the MAIL FROM of the
> resender.

I think we need to deal with the removal of return-path in a more
general way that's not specific to resending.

> Maybe there's an argument for removing a Return-Path before
> prepending the Resent-* fields, but that's a different discussion.

Exactly.

				Ned

Date: Wed, 2 May 2007 12:24:04 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: [2822upd] Resent-* MUSTard
Cc: Bruce Lilly <[email-masked]>, ietf-822 <[email-masked]>
Sender: [email-masked]

On 5/1/07 at 5:12 PM -0700, [email-masked] wrote:

>  > 2. Which Return-Path (2821 issue resurfaces); 2822 says "No other fields
>>     in the message are changed when resent fields are added", and taken at
>>     face value, that includes Return-Path.
>
>At the point where the redirection is done there isn't a 
>return-path, only an envelope. 2822bis does not and should not 
>discuss envelope issues - that's for 2821bis.

This is the one thing on which I disagree with Ned. It is perfectly 
reasonable to resend post-delivery. In that case, you'll have 
Resent-* fields prepended to the message which may already have a 
Return-Path. It will get a new Return-Path when it is delivered to 
the mailbox in the Resent-To, and that will be the MAIL FROM of the 
resender.

Maybe there's an argument for removing a Return-Path before 
prepending the Resent-* fields, but that's a different discussion.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated

To: [email-masked]
Xref: clerew local.mime:5004
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt)
Date: Wed, 2 May 2007 14:18:27 GMT
Lines: 23
Sender: [email-masked]

In <[email-masked]> "Charles Lindsey" <[email-masked]> writes:

>Let me recap what the problem is. Essentially, under RFC 2822 as it
>stands, '\a' is semantically equivalent to 'a' and agents are at liberty
>to change one into the other en route (of course, nobody ever writes '\a'
>and agents en route don't do that, but the possibility is there and some
>agents do check for those equivalances). Likewise, '"foobar"' is
>semantically equivalent to 'foobar'. Additionally, Netnews cannot tolerate
>SP or '>' (whether quoted or not) or any NO-WS-CTL.

I should have added there that Netnews also expects to do all comparisons
case-sensitively.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

To: [email-masked]
Xref: clerew local.mime:5005
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt)
Date: Wed, 2 May 2007 14:50:18 GMT
Lines: 30
Sender: [email-masked]

In <[email-masked]> Philip Guenther <[email-masked]> writes:

>Declaring no-fold-quote message-ids to be obsolescent seems reasonable to 
>me.  Note that all that would need to be done in the ABNF is remove 
>no-fold-quote from the id-left definition, as obs-id-left already covers 
>quoted-string.

>(Removing no-fold-literal from the generate syntax is a non-starter, IMHO. 
>Too many messages posted to this very list use them to even pretend that 
>they aren't widely supported and used.)

Indeed. The <no-fold-literal> is still needed, but its current syntax is
far too liberal compared with its envisaged use for conveying IP addresses.
So some trimming of that syntax could be considered.

Removing <quoted-pair> from it would remove most of the problem, and
defning a restricted version of <dtext> without NO-WS-CTL would do the
rest (it might even be a Good Idea to remove NO-WS-CTL from all
<dtext>s).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Wed, 2 May 2007 18:01:22 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: <quoted-string>s in <msg-id>s (Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt))
Cc: Philip Guenther <[email-masked]>
Sender: [email-masked]

Philip Guenther writes:
> On Wed, 2 May 2007, Arnt Gulbrandsen wrote:
> ...
>> One of formail, procmail and smartlist also generated message-ids 
>> containing quoted-string around that time. AFAICR the format was 
>> "word.word.word"@hostname.
>
> Yep.  That was formail and it stopped doing so in version 3.12, 
> released 1999-03-02

It's almost ten years ago, but perhaps you still remember why?

I'm assuming that the other three sources I've found (PP and unnamed 
gateways from XNS and X.400) stopped for similar reasons.

Arnt

Date: Wed, 2 May 2007 09:28:06 -0600
From: Philip Guenther <[email-masked]>
To: Arnt Gulbrandsen <[email-masked]>
cc: [email-masked]
Subject: Re: <quoted-string>s in <msg-id>s (Re: Compatibility wit Netnews (was  I-D ACTION:draft-resnick-2822upd-01.txt))
Sender: [email-masked]

On Wed, 2 May 2007, Arnt Gulbrandsen wrote:
...
> One of formail, procmail and smartlist also generated message-ids containing 
> quoted-string around that time. AFAICR the format was 
> "word.word.word"@hostname.

Yep.  That was formail and it stopped doing so in version 3.12, released 
1999-03-02

Philip Guenther

Date: Wed, 02 May 2007 08:29:18 -0600
From: Steve Hole <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: [2822upd] Resent-* MUSTard
Sender: [email-masked]

Bruce Lilly wrote:
> It appears from recent discussions that some clarification may well be
> desirable w.r.t. what is or isn't desired, and perhaps we need some
> discussion about desirability issues.
>
> To take an example, consider a case where A sends a message to B, and B
> resends to C, who happens to be on vacation.  Now a vacation autoresponder
> SHOULD use the Return-Path field for notification (3834 sect. 4), but:
>   
I'm afraid that the entire surmise (use case) here is broken from the 
get go.   This is NOT a resend, it is a forward.    Semantically they 
are hugely different and should be dealt with in entirely different 
ways.   Attempting to specify a slightly less broken method for dealing 
with a broken use case is not necessary and likely harmful to the other 
mainstream use cases that the language addresses today.

People have been misinterpreting the resend use cases for years.   A 
review of the proceedings leading up to 2821 and 2822 would be worth 
your time.

Cheers.

-- 
Steve Hole 
Chief Technical Officer
PlaNet Correspondence Technologies

424-4922 (wk)
905-9116 (mb)

mailto:[email-masked]

Date: Wed, 2 May 2007 12:14:50 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: <quoted-string>s in <msg-id>s (Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt))
Sender: [email-masked]

I looked at about a hundred thousand messages from the previous 
millenium and found three senders of quoted-string message-ids. Only 
one of the three needs the quotes, the other two presumably put them in 
to get that warm fuzzy feeling.

Here's smartlist at work:

Resent-Message-ID: <"0HHG2D.B.D3D.87oz0"@fiwi02>
Resent-Date: Wed, 28 Jan 1998 02:50:59 +0100
Return-Path: <[email-masked]>

Here's an X.400 gateway which didn't identify itself in Received:

Message-Id: <"28901 98/02/05 
04:04*/c=no/admd=telemax/prmd=telenor/o=fou/ou=lillehammer/s=xxx/g=yyy/"@MHS>

(All the messages from this gateway were from military institutions or 
badly managed state-owned telcos, so I assume someone on this list can 
guess which software this was.)

Finally I have some from PP, which I believe has transmogrified into 
isode.co.uk:

Message-ID: <"hauk.krs.h.675:13.03.97.19.33.00"@krs.hia.no>

Arnt

Date: Wed, 2 May 2007 11:34:00 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: <quoted-string>s in <msg-id>s (Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt))
Sender: [email-masked]

Kari Hurtta wrote, answering either Pete Resnick or Charles Lindsay:
>> But if 2822-bis is prepared to go further than that, then it is fine 
>> with me. The only question is whether people ever (or ever need to) 
>> use <quoted-string>s in <msg-id>s. I looked in all the news articles 
>> and
>>  emails on my computer and found no example of it, but my sample is 
>>  far too small. So has anyone else seen that in the wild?
>
> At least on my archive folder have some:
>
> $ egrep ^Message-ID: elm-mail-backup | fgrep '"'
> Message-ID: <"xlink100.x.795:21.07.96.17.56.16"@xlink.net>
> ...
> $
>
> These archived messages seems to be from year 1996

One of formail, procmail and smartlist also generated message-ids 
containing quoted-string around that time. AFAICR the format was 
"word.word.word"@hostname.

I've looked at around 100,000 recent message-ids and found none that 
required quoted-string.

Arnt

Date: Wed, 2 May 2007 00:23:36 -0600
From: Philip Guenther <[email-masked]>
To: ietf-822 <[email-masked]>
Subject: Re: [2822upd] Resent-* MUSTard
Sender: [email-masked]

On Tue, 1 May 2007, Bruce Lilly wrote:
...
> To take an example, consider a case where A sends a message to B, and B
> resends to C, who happens to be on vacation.  Now a vacation autoresponder
> SHOULD use the Return-Path field for notification (3834 sect. 4), but:
> 1. Many autoresponders use the From field.  <...>

They're broken.  "Fixing" them to prefer Resent-From over From is strictly 
worse than truly fixing them to use Return-Path or out-of-band knowledge 
of the envelope sender.  Note that a program using Resent-From instead of 
Return-Path is still going to get the critical case of mailing lists 
wrong.

(In my experience, very few mailing lists add Resent-* header fields...and 
I wish the few that did would stop doing so.)

> 2. Which Return-Path (2821 issue resurfaces);
...
>   What the recipient gets depends
>   on whether SMTP (2821) is involved (if C is local to B, some non-SMTP
>   local delivery might be used, in which case Return-Path might still be
>   present, still pointing to A, and leading to the same sort of confusion
>   as above).

RFC 2822, by itself, does not guarantee that the message will contain the 
address to which vacations and bounces will be sent.  That is correct. 
If you happen to operate in an non-SMTP environment, then the 
representation of envelope information is a matter for that environment to 
define and mail handling program that support that environment will need 
to be aware of that definition.

(I can imagine a "circuit-switched email" environment where the 'envelope 
sender' is not an email address at all but rather an end-point address in 
a completely different namespace, such that the idea of "sending an DSN" 
as an email message is nonsensical.  An auto-responder there would be a 
much different beast and nothing we say in RFC 822ter will make an 
SMTP-aware vacation program 'portable' to that other environment.)

>   Even if SMTP is used, the issues of whether or not to elide
>   Return-Path when adding a new one, and which Return-Path field should
>   be used if there is more than one such field determine what may happen.

draft-klensin-rfc2821bis-03.txt, section 4.4:
    When the delivery SMTP server makes the "final delivery" of a
    message, it inserts a return-path line at the beginning of the mail
    data.  This use of return-path is required; mail systems MUST support
    it.  <...>

The new field is inserted at the beginning, ergo, if a message was most 
recently transported by SMTP, then the first Return-Path field is the 
envelope-sender from that SMTP transaction.  If the most recent transport 
wasn't SMTP, consult the documentation for that transport.

Philip Guenther

To: [email-masked]
From: Kari Hurtta <[email-masked]>
Subject:  <quoted-string>s in <msg-id>s (Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt))
Date:  01 May 2007 20:53:11 +0300
Lines: 28
Cc: Kari Hurtta <[email-masked]>
Sender: [email-masked]

"Charles Lindsey" <[email-masked]> writes in gmane.ietf.rfc822:

> In <p06300002c25bc5f3f74b@[216.43.25.67]> Pete Resnick <[email-masked]> writes:
> 
> >On 4/27/07 at 7:02 PM +0000, Charles Lindsey wrote:
> But if 2822-bis is prepared to go further than that, then it is fine with
> me. The only question is whether people ever (or ever need to) use
> <quoted-string>s in <msg-id>s. I looked in all the news articles and
> emails on my computer and found no example of it, but my sample is far too
> small. So has anyone else seen that in the wild?

At least on my archive folder have some:

$ egrep ^Message-ID: elm-mail-backup | fgrep '"'
Message-ID: <"xlink100.x.795:21.07.96.17.56.16"@xlink.net>
Message-ID: <"xlink100.x.564:21.07.96.17.47.43"@xlink.net>
Message-ID: <"xlink100.x.588:21.07.96.17.48.05"@xlink.net>
Message-ID: <"xlink100.x.798:21.07.96.17.50.08"@xlink.net>
Message-ID: <"xlink100.x.798:21.07.96.17.50.08"@xlink.net>
Message-ID: <"xlink100.x.621:23.07.96.07.52.42"@xlink.net>
Message-ID: <"xlink100.x.080:21.07.96.10.22.30"@xlink.net>
Message-ID: <"xlink100.x.657:21.07.96.08.18.19"@xlink.net>
Message-ID: <"xlink100.x.900:21.07.96.07.54.41"@xlink.net>
$                                               

These archived messages seems to be from year 1996

/ Kari Hurtta

From: [email-masked]
Cc: ietf-822 <[email-masked]>
Date: Tue, 01 May 2007 17:12:47 -0700 (PDT)
Subject: Re: [2822upd] Resent-* MUSTard
To: Bruce Lilly <[email-masked]>
Sender: [email-masked]

> On 2007-05-01, Pete Resnick wrote:

> > ...or creating address book entries or filtering based on author of
> > the text or sorting by date or..... Hey, since there's so many things
> > that MUAs might automatedly do on messages in which they should look
> > at From/Date/etc. instead of Resent-From/Resent-Date/etc., why don't
> > we say "replying and things like that." Oh.....

> It appears from recent discussions that some clarification may well be
> desirable w.r.t. what is or isn't desired, and perhaps we need some
> discussion about desirability issues.

> To take an example, consider a case where A sends a message to B, and B
> resends to C, who happens to be on vacation.  Now a vacation autoresponder
> SHOULD use the Return-Path field for notification (3834 sect. 4), but:
> 1. Many autoresponders use the From field. In this case, A might not
>    know who C is, hasn't sent the message to C, and may well be confused
>    if he gets an auto-response referring to a message that it is claimed
>    he sent to C.  In this case using the From field yields worse results
>    than using Resent-From (or Resent-Sender vs. Sender); B probably knows
>    C, and might conceivably be interested to know that the meesage that
>    he resent to C might not be read for a while.

OK, so the logic here is that if you're going to break the rules, you should as
your second option fall back to behavior that doesn't cause quite as much
breakage? I'm sorry, but I see little advantage to describing this approach,
esecially since it would drag 2822bis into dealing with issues having more to
do with SMTP envelopes than with message formats.

> 2. Which Return-Path (2821 issue resurfaces); 2822 says "No other fields
>    in the message are changed when resent fields are added", and taken at
>    face value, that includes Return-Path.

At the point where the redirection is done there isn't a return-path, only
an envelope. 2822bis does not and should not discuss envelope issues - that's
for 2821bis.

It is *absolutely* the case that a return-path field should not be part of the
redirected message. The creation of the return-path is the job of the final
delivery agent.

>    What the recipient gets depends
>    on whether SMTP (2821) is involved (if C is local to B, some non-SMTP
>    local delivery might be used, in which case Return-Path might still be
>    present, still pointing to A, and leading to the same sort of confusion
>    as above).  Even if SMTP is used, the issues of whether or not to elide
>    Return-Path when adding a new one, and which Return-Path field should
>    be used if there is more than one such field determine what may happen.
>    2822 is also unclear on this; see above re. "No other fields [...]",
>    vs. the ABNF (and text "an optional") specification of at most one
>    Return-Path field vs. "Except for destination address fields [...] the
>    interpretation of multiple occurrences of fields is unspecified".

I'm sorry, but I see no point in discussing the setting of a field which at
best would be used by private arrangement to some sort of non-SMTP submission
agent.

> 3. I did NOT suggest that a "Resent-Return-Path" field might be in order...

THank goodness.

> 4. Security Considerations should mention the possibilities for abuse (e.g.
>    using the rules re. non-use of Resent- fields by "automated actions"
>    to disguise the source of spam, etc.)

This I do agree with, although I'm not entirely clear what should be
said.

> Clear definitions may help greatly. E.g. 2822 is pretty clear that the
> author is specified by the From field; therefore Resent-From specifies
> something other than the author.  One area that needs clarification is the
> definition of "user", which should be consistent among the documents
> discussing applications of the message format.  2822 says w.r.t. Resent-
> fields "Resent fields are used to identify a message as having been
> reintroduced into the transport system by a user"; I know of at least one
> document that states that a mailing list exploder is a "user", which is
> probably inconsistent with 2822's intent regarding Resent- fields...

I also have no problem with clarification of definitions, but specific
suggestions would be nice...

				Ned

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: [2822upd] Resent-* MUSTard
Date: Tue, 1 May 2007 18:28:46 -0400
Sender: [email-masked]

On 2007-05-01, Pete Resnick wrote:

> ...or creating address book entries or filtering based on author of 
> the text or sorting by date or..... Hey, since there's so many things 
> that MUAs might automatedly do on messages in which they should look 
> at From/Date/etc. instead of Resent-From/Resent-Date/etc., why don't 
> we say "replying and things like that." Oh.....

It appears from recent discussions that some clarification may well be
desirable w.r.t. what is or isn't desired, and perhaps we need some
discussion about desirability issues.

To take an example, consider a case where A sends a message to B, and B
resends to C, who happens to be on vacation.  Now a vacation autoresponder
SHOULD use the Return-Path field for notification (3834 sect. 4), but:
1. Many autoresponders use the From field. In this case, A might not
   know who C is, hasn't sent the message to C, and may well be confused
   if he gets an auto-response referring to a message that it is claimed
   he sent to C.  In this case using the From field yields worse results
   than using Resent-From (or Resent-Sender vs. Sender); B probably knows
   C, and might conceivably be interested to know that the meesage that
   he resent to C might not be read for a while.
2. Which Return-Path (2821 issue resurfaces); 2822 says "No other fields
   in the message are changed when resent fields are added", and taken at
   face value, that includes Return-Path.  What the recipient gets depends
   on whether SMTP (2821) is involved (if C is local to B, some non-SMTP
   local delivery might be used, in which case Return-Path might still be
   present, still pointing to A, and leading to the same sort of confusion
   as above).  Even if SMTP is used, the issues of whether or not to elide
   Return-Path when adding a new one, and which Return-Path field should
   be used if there is more than one such field determine what may happen.
   2822 is also unclear on this; see above re. "No other fields [...]",
   vs. the ABNF (and text "an optional") specification of at most one
   Return-Path field vs. "Except for destination address fields [...] the
   interpretation of multiple occurrences of fields is unspecified".
3. I did NOT suggest that a "Resent-Return-Path" field might be in order...
4. Security Considerations should mention the possibilities for abuse (e.g.
   using the rules re. non-use of Resent- fields by "automated actions"
   to disguise the source of spam, etc.)

Clear definitions may help greatly. E.g. 2822 is pretty clear that the
author is specified by the From field; therefore Resent-From specifies
something other than the author.  One area that needs clarification is the
definition of "user", which should be consistent among the documents
discussing applications of the message format.  2822 says w.r.t. Resent-
fields "Resent fields are used to identify a message as having been
reintroduced into the transport system by a user"; I know of at least one
document that states that a mailing list exploder is a "user", which is
probably inconsistent with 2822's intent regarding Resent- fields...

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: [2822upd] Resent-* MUSTard
Date:  Tue, 01 May 2007 23:30:35 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 56
Sender: [email-masked]

Pete Resnick wrote:
 
> I think SenderID plays fast and loose with Resent-*, and even if some
> of the things that it does are fine, some of the things it expects to
> happen are....shall we say, "experimental".

Putting it mildly, yes.   Maybe you've seen the other appeal, which in
fact did go to the IAB.  Unfortunately they decided that an experiment
doing "experimental" things with other RFCs or experiments is just that,
"experimental".

> like Ned I am suspicious of the way the "experiment" is being done. 

Sometimes they publish news aggregating the numbers of their experiment
with the numbers of the other experiment, because they claim that this
is "backwards compatibility".  It's ordinary embrace-extend-extinguish,
and as far as I'm concerned unethical behaviour.  The appeals are on
public record, enough said.

  [back to the MUST NOT]
>> How about rewording this statement:

>>+ mainly informational.  They MUST NOT be used in the normal
>>+ processing of replies or the creation of auto-responses [RFC 3834].
 
> ...or creating address book entries or filtering based on author of
> the text or sorting by date or..... Hey, since there's so many things
> that MUAs might automatedly do on messages in which they should look
> at From/Date/etc. instead of Resent-From/Resent-Date/etc., why don't
> we say "replying and things like that." Oh.....

Yes, why don't we ?  Maybe William misunderstood the statement, and I
also was never sure what "or other such automatic processing" is about,
only the replying or something more general.     

  [MIME forward vs. resend]
>> the desired effect is often the same, I got a mail and want you to 
>> read it.
 
> No, no, no. That's not what resending is for. As Dave Crocker said
> (in the jabber log noted in William's appeal), "Resent-* was designed
> to splice a new recipient into a direct exchange with the original
> author", not just to send a piece of mail I got to you.

Okay, can we say that in 2822upd ?  Maybe it's only me who thought
that it's a poor alternative to a MIME forward.  But if it's not only
me saying what it's designed for can help other readers to understand
the concept.

> The rest of your message I think Philip answered as I would have.

Yes, my attempt to get rid of Resent-From came about 25 years too late,
and after all it's not impossible to fix the "may add sender" in 4409.

Frank

From: [email-masked]
Cc: [email-masked]
Date: Tue, 01 May 2007 10:57:35 -0700 (PDT)
Subject: Re: [2822upd] Resent-* MUSTard
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

> [email-masked] wrote:

> > It is in no way incumbent on this effort to change 2822bis to be
> > compatible with either of these experiments, especially since the
> > two experiments are incompatible with each other!

> One of these experiments is strictly limited to SMTP, we can ignore
> it here.  I think it's a bit unfair to say that the other experiment
> is incompatible with 2822, when 2822 gives no reason why there's an
> offending MUST NOT about Resent-* in automatic processing.

Reread my statement. Nowhere did I say that SPF, or sender-id for that matter,
was incompatible with 2822. What I said was, rather, that due to the
experimental status of this proposals any incompatibility they present is not
our concern.

I'm not going to get into whether or not I actually regard SPF as an
incompatible mechanism with existing email standards because all it's going to
do is get us into an argument that's irrelevant to the matter at hand.

> I'm too lazy to dig through MARID jabber logs now, but IIRC the PRA
> concept was discussed in presence of the 822 and 2822 editors among
> others.  It makes me wonder how important this MUST NOT is, and how
> it's justified, I think there's nothing similar in 822.

> >> In fact I think 2822upd should fix this issue.
> > Then you need to make a very compelling argument for the change

> For the MUST NOT I'd like to know a compelling reason why it's there,
> otherwise 2119 might suffice to remove unnecessary MUSTard.

Um, nonsense. It's easy to apply 2119 criteria to MUSTs or even SHOULDs since
they typically require some effort to implement. You look for multiple
interoperating implementations and if there aren't any out comes the feature.

MUST NOT and SHOULD NOT are another story. There are bound to be conforming
implementaqtions because it is almost always easier not to do something than to
do it and that leads to a form of compliance, vacuous though it may be. And all
examples of nonconfirming implementation do is show that a fair number of
people cannot write compliant code - what else is new?

The two ways to successfully challenge a MUST NOT or a SHOULD NOT would
be if you can show there were objections during the standardization
process that weren't given adequate consideration - the claim of consensus
for the feature is bogus, in other words. Or you can demonstrate that
the prohibition is for some reason a bad idea - such as if it creates
a serious security issue.

Regardless, the main point here is that it is not our job to provide a case to
support the inclusion of this facility, but rather it's your job to make a
convincing case that it should be removed.

> > some evaporate leaving only a very bad smell behind.

> In the case of the PRA I'm curious if a part of its bad smell was
> caused by an unnecessary / unclear / dubious / ... MUST NOT in 2822.

This was a comment about the results of Internet experiments in general, not a
comment on the likely or even possible outcomes of these experiments
specifically.

> > > Who needs a Resent-Sender ?

> > Resent-sender exists for the same reason Sender: does. I see nothing
> > that would prevent a resending operation from involving multiple
> > authoring parties with one distinghished reponsible party.

> I use MIME when I forward mails or news, not Resent-*, but even if
> I'd use Resent-* I don't see why there could be multiple "authors"
> in the case of resent mail.

It's just one example.

> Is that a committee reading a mail
> written by somebody else, collectively deciding to forward this
> mail to a third party, with the names of all committee members in
> the Resent-From, and the notorious Resent-Sender: secy@ ?

Why not? And I can think of many more examples, such as one coauthor
resending a review of their book.

The better example though is when the user has specified an alternate from as
part of their resending operation and the user agent wants to insert the user's
real email address.

> Really, I
> don't get it, who needs or uses this syntactical option ?  Why can't
> we deprecate it in 2822bis ?

Because there are cases where it is useful and needed. Really, what I cannot
fathom is wanting to create an unnecessary and ugly asymmetry between original
field semantics in the sending and resending cases.

> > In fact our usage of resent- fields in general (although not
> > resent-sender specifically) has actually increased of late because
> > of the desire of several sites to be able to track and audit user-
> > level message redirection in things like sieve filters. This is
> > definitely not something you want to do with nested MIME structure.

> I'm not sure I get what you're saying, do you have a simple example ?

That's sort of the point - the examples of this are anything but simple.
Email-based workflow applications exist that end up redirecting a single
message many times. Even if you believe it is OK to use MIME forwarding for
this (I don't - I think the semantics are wrong) you really should check and
see what happens when some user agents try and handle this sort of structure. 

> If SIEVE processing uses Resent-*, doesn't it have a similar issue
> with the MUST NOT in 2822 ?

Because there is no conflict. As Pete has pointed out, you appear not to
understand what the text is saying. Sieve redirect in particular causes
reintroduction of the message into the transport system and is NOT in any way
shape or form a reply, automatic or otherwise.

> > > Why is there more than one Resent-* block incompatible with
> > > RFC 821, and resulting in yet another incompatibility with
> > > RFC 4407 ?  Why can't we deprecate this rubbish in favour of the
> > > much clearer MIME forwarding ?

> > I would have been willing to entertain doing that as part of the
> > DRUMS effort, but removing a fairly significant facility as part
> > of this late-stage cleanup exercise strikes me as quite a bit more
> > than we're really supposed to be doing here.

> Well, the SenderID RFCs aren't the only "victim" of this stuff, it's
> also an obstacle for things like 4409 8.1, or (maybe) for DKIM SSP,
> situations where folks try to do something interesting with mail
> headers while ignoring SMTP envelopes (in the case of DKIM a design
> decision).

I have already stated that I view the 4409 issue as a 4009 bug. As for DKIM
SSP, since it is not complete it is hard to say, but if there's a conflict the
right place to deal with it is with a separate activity after the problem has
been identified and fully characterized.

				Ned

Date: Tue, 1 May 2007 13:20:56 -0500
To: Frank Ellermann <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: [2822upd] Resent-* MUSTard
Cc: [email-masked]
Sender: [email-masked]

On 5/1/07 at 7:01 AM +0200, Frank Ellermann wrote:

>Pete Resnick wrote:
>
>>2822 does not say that Resent-* "MUST NOT be used in automatic 
>>processing". Don't partially quote. Read it again, in context.
>
>I've read it several times because William quoted it in his appeal
><http://www.ietf.org/IESG/APPEALS/appeal2-draft-lyon-senderid.txt>
>
>He quoted the "note" adding two references to statements by you.

Had I been asked (the appeal never went to the IAB, at least while I 
was there), I would have said that William got his interpretation of 
my comments wrong.

>And he quoted the immediately preceding MUST NOT about Resent-* in 
>automatic processing as separate argument.  If you think that this 
>"MUST NOT" doesn't affect whatever SenderID does, then the context 
>needs to be clearer.

Au contraire, I think SenderID plays fast and loose with Resent-*, 
and even if some of the things that it does are fine, some of the 
things it expects  to happen are....shall we say, "experimental". But 
because it is in fact experimental, I don't mind that it violates the 
MUST NOT. If the SenderID experiment succeeds in this respect and it 
turns out that this kind of automatic processing is not like 
"processing replies or other such automatic actions" (in that it 
*can* be done interoperably), then SenderID can become standards 
track, include "Update: RFC 2822" in its masthead, and include a 
paragraph that says, "After experimentation, we have determined that 
the action we do is not like replies or other such automatic actions 
referred to in RFC 2822 3.6.6, and therefore it's OK to use Resent-* 
fields for this purpose." However, like Ned I am suspicious of the 
way the "experiment" is being done. Personally, I think SenderID will 
find that it can't depend on Resent-* for its actions.

So, the current text I think is a correct assessment of the current 
state of the world. If SenderID finds that it is not like replying, 
it can say that.

>How about rewording this statement:
>
>+ mainly informational.  They MUST NOT be used in the normal
>+ processing of replies or the creation of auto-responses [RFC 3834].

...or creating address book entries or filtering based on author of 
the text or sorting by date or..... Hey, since there's so many things 
that MUAs might automatedly do on messages in which they should look 
at From/Date/etc. instead of Resent-From/Resent-Date/etc., why don't 
we say "replying and things like that." Oh.....

>>Resent-* are *never* used when you "forward".
>
>Sure, but the desired effect is often the same, I got a mail and 
>want you to read it.

No, no, no. That's not what resending is for. As Dave Crocker said 
(in the jabber log noted in William's appeal), "Resent-* was designed 
to splice a new recipient into a direct exchange with the original 
author", not just to send a piece of mail I got to you. MUAs behave 
*very* differently when presented with a MIME-forwarded (or otherwise 
forwarded) piece of mail than they do with a resent one.

The rest of your message I think Philip answered as I would have.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated

Date: Tue, 1 May 2007 11:02:16 -0600
From: Philip Guenther <[email-masked]>
To: Charles Lindsey <[email-masked]>
cc: [email-masked]
Subject: Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt)
Sender: [email-masked]

On Tue, 1 May 2007, Charles Lindsey wrote:
...
> But if 2822-bis is prepared to go further than that, then it is fine with
> me. The only question is whether people ever (or ever need to) use
> <quoted-string>s in <msg-id>s. I looked in all the news articles and
> emails on my computer and found no example of it, but my sample is far too
> small. So has anyone else seen that in the wild?

In a scan of the messages I have lying around, I found only one message 
whose message-id contained a quote...but it matched the old obs-local-part 
syntax and not the no-fold-quote syntax!

Message-Id: <07Mar26.165721pst."57996"@xxx.yyy.zzz.com>

Declaring no-fold-quote message-ids to be obsolescent seems reasonable to 
me.  Note that all that would need to be done in the ABNF is remove 
no-fold-quote from the id-left definition, as obs-id-left already covers 
quoted-string.

(Removing no-fold-literal from the generate syntax is a non-starter, IMHO. 
Too many messages posted to this very list use them to even pretend that 
they aren't widely supported and used.)

Philip Guenther

To: [email-masked]
Xref: clerew local.mime:4984
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt)
Date: Tue, 1 May 2007 13:39:02 GMT
Lines: 64
Sender: [email-masked]

In <p06300002c25bc5f3f74b@[216.43.25.67]> Pete Resnick <[email-masked]> writes:

>On 4/27/07 at 7:02 PM +0000, Charles Lindsey wrote:

>>Indeed, the Message-ID is the principal feature of RFC 2822 which 
>>could not be incorporated into Netnews as it stood.

>I had a look at the USEFOR doc, and given how complicated msg-id 
>syntax still is, I can't say I'm terribly inclined to start adopting 
>it. If USEFOR had come to consensus to completely remove the 
>no-fold-quote construct, I'd be a little more inclined.

I would have no problem with doing that, and it would pretty well solve
the problem (you would also need to do something about <no-fold-literal>).

Let me recap what the problem is. Essentially, under RFC 2822 as it
stands, '\a' is semantically equivalent to 'a' and agents are at liberty
to change one into the other en route (of course, nobody ever writes '\a'
and agents en route don't do that, but the possibility is there and some
agents do check for those equivalances). Likewise, '"foobar"' is
semantically equivalent to 'foobar'. Additionally, Netnews cannot tolerate
SP or '>' (whether quoted or not) or any NO-WS-CTL.

So abolishing <no-fold-quote> pretty well solves the problem. The reason
USEFOR did not do that is that it did not want to change anything allowed
by RFC 2822 more than was absolutely necessary. So it disallows '\a' and
'"foobar"' but it allows '\\' and '"foo..bar"' - and the syntax that
enforces that is absolutely horrid, as you can imagine (but it works).

But if 2822-bis is prepared to go further than that, then it is fine with
me. The only question is whether people ever (or ever need to) use
<quoted-string>s in <msg-id>s. I looked in all the news articles and
emails on my computer and found no example of it, but my sample is far too
small. So has anyone else seen that in the wild?

But whatever we do, plese let it be normative. If you don't want people to
generate certain things in the future (we don't care what is left in the
obs-syntax), then say so and be done with it.

> But things 
>like the "dot-doubling" worry me. (For example, as it stands, all of 
>the following are still legal msg-ids under USEFOR:

>"."@[]
>".."@[]
>"..."@[]
>"...."@[]
>"....."@[]
>"......"@[]

Yes, those are all ugly, but they are allowed by RFC 2822 and do no harm
in Netnews (except that only one email/article is ever allowed to contain
each of them, because of the globally unique requirement :-) ).

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5

Date: Tue, 1 May 2007 01:05:50 -0600
From: Philip Guenther <[email-masked]>
To: Frank Ellermann <[email-masked]>
cc: [email-masked]
Subject: Re: [2822upd] Resent-* MUSTard
Sender: [email-masked]

On Tue, 1 May 2007, Frank Ellermann wrote:
> Pete Resnick wrote:
...
>>> I use MIME when I forward mails or news, not Resent-*
>
>> Resent-* are *never* used when you "forward". That is also said in
>> quite clearly in 3.6.6 (in the Note).
>
> Sure, but the desired effect is often the same, I got a mail and want
> you to read it.  I can MIME-forward or resend it to you.  With MIME I
> can add a reason why I think that it might interest you, with MIME I
> can also forward more than mail.  But if I don't pick any additional
> option offered by MIME the effect is almost the same, you get the
> original mail incl. original header and original body.

I'm not sure I would even call the effects of resending vs encapsulating 
_similar_, much less "almost the same".  The very fact that they behave 
differently is a Good Thing, as it means they can express differences in 
intent.  When I want to add someone to a conversational thread, I resend 
to them the latest message (occasionally more than one) so that their 
replies naturally go back to the current set of recipients.  When I want 
to inform someone of something or start a side conversation, I forward it 
to convey that replies probably should go back to me.  They can reply 
however they want, of course, but it conveys my intent and helps avoid 
misaddressing.

Heck, the difference between resending and forwarding is *much* greater 
than the difference between To and Cc recipients.

>>> I don't see why there could be multiple "authors"
>
>> So you've backed off of your original argument about the need for
>> Resent-Sender (because it is needed when Resent-From is not identical
>> to the sender) and you're just complaining about Ned's example?
>
> Not really.  But it would be easy to convince me that the Resent-From
> is actually unnecessary, keeping the Resent-Sender.

That would completely break backwards compatibility, rendering all 
software that generates Resent-* non-compliant.  If your intent is simply 
to break a feature you don't like, please say so.

>> I think it's more important for interoperability of implementations
>> to keep the syntax of Resent-From and From identical (and the way
>> it's always been) than to go verify that nobody is using this
>> particular feature.
>
> Have you seen my proposed fix for RFC 4409 8.1 ?  It's clumsy if there
> are both kinds, Resent-From and Resent-Sender.
...
> Here's an older version of the 4409 proposal:
> <http://permalink.gmane.org/gmane.ietf.rfc822/11805>

A clumsy fix is better than a wrong fix.  Off hand, I think discussion of 
Resent-* in a 4409bis should not be restricted to Resent-Sender, as it may 
be appropriate for the MSA to add Resent-Date and/or Resent-Message-Id as 
well.  Also, the last two paragraphs of your suggested change at the above 
URL seem undesirable or out of scope to me.

>> And I, and a bunch of other folks that I know, will scream bloody
>> murder if you take that feature out of our mail clients. Forwarding
>> (MIME or otherwise) does not have the same functionality as resending
>
> MIME has more functionality, you're not forced to use it if you don't
> like it.  I often send mails with Content-Type: message/rfc822, with
> an indicator in the subject why I did that if it's for a human reader.

1) that's not "more functionality"; that's *different* functionality.
    Encapsulation is not a superset of resending.

2) "not forced to use it"  Saying that after you suggest deprecating
    or breaking Resent-* seems disingenuous.

> There's no "Resent-subject", what are you doing that can't be done
> with MIME, threading based on the original references ?

Yeah, you're right, that's *another* feature of resending that 
encapsulation can't reproduce.

Philip Guenther

Date: Tue, 1 May 2007 09:05:25 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt)
Cc: Pete Resnick <[email-masked]>, [email-masked], Dave Crocker <[email-masked]>, Charles Lindsey <[email-masked]>
Sender: [email-masked]

Dave Crocker writes:
> In effect, the issue here is defining a sub-set profile that permits 
> gatewaying between Internet mail and Netnews.  A thoroughly laudable 
> goal, but not one for RFC2822bis...

Mumble.

Netnews may be an important reason why no-fold-quote and its kid aren't 
used in message-ids. But the reason doesn't matter for 2821bis: 
Standards-track documents are supposed to drop unused features as they 
progress, no matter why these features are unused.

Arnt