Subject: Re: [2822upd] Resent-* MUSTard
From: Frank Ellermann <[email-masked]>
To: [email-masked]
Date: Tue, 01 May 2007 07:01:45 +0200
List-Id: <ietf-822.imc.org>

Pete Resnick wrote:

>> 2822 gives no reason why there's an offending MUST NOT about
>> Resent-* in automatic processing.

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

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.

> As for why: It is because there was confusion about what MUAs ought
> to do with those fields, and using them for the reply command, and
> "*OTHER SUCH* actions" (was enough emphasis added?) would do the
> wrong thing.

How about rewording this statement:

- strictly informational.  They MUST NOT be used in the normal
- processing of replies or other such automatic actions on messages.
+ mainly informational.  They MUST NOT be used in the normal
+ processing of replies or the creation of auto-responses [RFC 3834].

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

> 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.  And RFC 4407 also has
its difficulties to arrive at a "PRA" in the presence of both kinds.

Here's an older version of the 4409 proposal:
<http://permalink.gmane.org/gmane.ietf.rfc822/11805>

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

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

Frank

Date: Mon, 30 Apr 2007 22:23:54 -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 3:46 AM +0200, Frank Ellermann wrote:

>2822 gives no reason why there's an offending MUST NOT about 
>Resent-* in automatic processing.

2822 does not say that Resent-* "MUST NOT be used in automatic 
processing". Don't partially quote. Read it again, in context.

As for why: It is because there was confusion about what MUAs ought 
to do with those fields, and using them for the reply command, and 
"*OTHER SUCH* actions" (was enough emphasis added?) would do the 
wrong thing.

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

>but even if I'd use Resent-* 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?

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.

>>>Why can't we deprecate this rubbish in favour of the much clearer 
>>>MIME forwarding ?

Because it is not forwarding. It is resending. 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 and therefore does not 
address the same problem.

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: [2822upd] Resent-* MUSTard
Date:  Tue, 01 May 2007 03:46:20 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 107
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.

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.

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

> It might arguably make sense to alter tnings based on the *outcome*
> of an experiment, but probably not as part of what's supposed to be
> a simple document cleanup effort.

I'm not actively watching this experiment.  But because it's as you
mentioned incompatible with the SMTP "experiment" it might be still
more than nothing when I note that I've so far not heard of practical
problems with its violation of the 2822 MUST NOT.

=== side note ===
> On a side note, the main reason I opposed the publication of these
> experiments is because they did not even consider the issue of how
> to assess their own results. Had this issue been considered I don't
> see how the inherent semantic conflists between the two could have
> been allowed to stand.

At some point "we" (SPF supporters) had to give up.  We proposed PS,
that was rejected, we proposed IETF Last Call, that was rejected, we
appealed to the IESG, that didn't have the desired effect of removing
four letters resulting in the incompatibility, and we appealed to the
IAB, again no success wrt the four letters.  And after that the last
theoretical option was refusing to publish the RFC because another
memo abused it, unsurprisingly there was no consensus to go that far.
Besides "do not publish" is a bad idea (admittedly I considered it).

=== back to 2822 ===
>> 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.  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@ ?  Really, I
don't get it, who needs or uses this syntactical option ?  Why can't
we deprecate it in 2822bis ?

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

>> Why is the complete Resent-nightmare not supported in RFC 4409 8.1
>> "may add sender" ?

> I actually see this as more of a a bug in RFC 4409 than anything else.

Yes, I failed to convince John that this could be fixed in a 4409bis.
And he failed to convince me that it could be published as separate
RFC if I think it's important.  My willingness to clean up the mess
caused by SenderID didn't go that far.  I could be persuaded to try
it, after all it's less than one 69*62 page (without boilerplates).

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

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Compatibility wit Netnews  (was I-D ACTION:draft-resnick-2822upd-01.txt)
Date:  Tue, 01 May 2007 02:24:04 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 21
Sender: [email-masked]

Pete Resnick wrote:

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

USEFOR was forced to determine a maximal subset of 2822-Message-IDs
still working for its purposes, so that's a hen and egg issue.  If
2882upd removes <no-fold-quote> (still covered by "obs" of course)
then USEFOR can also get rid of it, I like the idea.  Syntactically
<no-fold-quote> is also a pain for I-D.ellermann-news-nntp-uri-05

> things like the "dot-doubling" worry me

It's only a consequence of how <dot-atom-text> is specified in 2822. 
Leading, trailing, or adjacent dots aren't allowed in dot-atom-text,
if folks want them anyway they have to use <no-fold-quote>.

Frank

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-resnick-2822upd-01.txt
Organization: The Eyrie
Date: Mon, 30 Apr 2007 17:22:27 -0700
Sender: [email-masked]

Frank Ellermann <[email-masked]> writes:

> For the <msg-id> I'd like to see a syntax also working in NetNews, in
> news URIs, and in Archived-At links when they use a Message-ID.

For completeness, here's what RFC 3977 says about message IDs as used in
the NNTP protocol:

A.2.  Message-IDs

   Every article handled by an NNTP server MUST have a unique
   message-id.  For the purposes of this specification, a message-id is
   an arbitrary opaque string that merely needs to meet certain
   syntactic requirements and is just a way to refer to the article.

   Because there is a significant risk that old articles will be
   reinjected into the global Usenet system, RFC 1036 [RFC1036] requires
   that message-ids are globally unique for all time.

   This specification states that message-ids are the same if and only
   if they consist of the same sequence of octets.  Other specifications
   may define two different sequences as being equal because they are
   putting an interpretation on particular characters.  RFC 2822
   [RFC2822] has a concept of "quoted" and "escaped" characters.  It
   therefore considers the three message-ids:

      <[email-masked]>
      <"ab.cd"@example.com>
      <"ab.\cd"@example.com>

   as being identical.  Therefore, an NNTP implementation handing email
   articles must ensure that only one of these three appears in the
   protocol and that the other two are converted to it as and when
   necessary, such as when a client checks the results of a NEWNEWS
   command against an internal database of message-ids.  Note that
   RFC 1036 [RFC1036] never treats two different strings as being
   identical.  Its successor (as of the time of writing) restricts the
   syntax of message-ids so that, whenever RFC 2822 would treat two
   strings as equivalent, only one of them is valid (in the above
   example, only the first string is valid).

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt)
Date:  Tue, 01 May 2007 02:13:28 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 19
Sender: [email-masked]

Arnt Gulbrandsen wrote:
 
>> If we want normative language like the above, we should really
>> just remove no-fold-quote (since quoted-string is already allowed
>> in the obs- syntax).
 
> Makes sense to me. Particularly since you can look for a long time
> before you find no-fold-quote in real message-ids. Standards are
> supposed to drop unused features as they advance, right?

Killing <no-fold-quote> is a nice idea, it simplifies the syntax
significantly.

And what about NO-WS-CTL in <no-fold-literal> ?  We can't also kill
<no-fold-literal>, how about limiting it to the literal syntax also
permitted in STD 66 ?  (Of course always in square brackets)
 
Frank

From: Russ Allbery <[email-masked]>
To: [email-masked]
Subject: Re: Compatibility wit Netnews
Organization: The Eyrie
Date: Mon, 30 Apr 2007 17:19:10 -0700
Sender: [email-masked]

Pete Resnick <[email-masked]> writes:

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

Er, the only reason why we didn't do that is for RFC 2822 compatibility.
I sense a deadlock.  :)

NNTP would certainly love to eliminate as many quoting concepts as
possible out of message IDs, and in general any construct that permits the
same message ID to be represented by multiple different octet strings.

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Compatibility wit Netnews
Date:  Tue, 01 May 2007 02:04:12 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 24
Sender: [email-masked]

Arnt Gulbrandsen wrote:

>> I'd rather stick with the liberal syntax for now, and maybe add a note=

>> that says, "You SHOULD be conservative in what you generate, as
>> NO-WS-CTLs, quoted-pairs, and specials are known to cause heartburn
>> in some environments (cf. USEFOR)."
 =

> +1. Proposed text: =ABIt is RECOMMENDED to use only A-Z, a-z, 0-9, ".",=

> "." and "/" on the left-hand side, and to make the left-hand side at
> most 64 characters long. Unusual but permitted syntax such as (for
> example) quoted-pairs are known to cause problems in some contexts.=BB

-1  =

Where's the evidence that NO-WS-CTL is implemented AND interoperable ?
It's IMO harmful and a showstopper for DS.  It can't pass any gateway
to NetNews if used in Message-IDs.

Frank

Date: Mon, 30 Apr 2007 14:50:06 -0700
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Pete Resnick <[email-masked]>
CC: Arnt Gulbrandsen <[email-masked]>, [email-masked], Charles Lindsey <[email-masked]>
Subject: Re: Compatibility wit Netnews (was I-D   ACTION:draft-resnick-2822upd-01.txt)
Sender: [email-masked]

Pete Resnick wrote:
>> Pete Resnick writes:
>>> I'd rather stick with the liberal syntax for now, and maybe add a note
>>> that says, "You SHOULD be conservative in what you generate, as 
>>> NO-WS-CTLs, quoted-pairs, and specials are known to cause heartburn in
>>> some environments (cf. USEFOR)."
>> 
>> +1. Proposed text: «It is RECOMMENDED to use only A-Z, a-z, 0-9, ".",
...
> So, now I'm beginning to get uneasy about using SHOULD/RECOMMENDED in here.
> If we want normative language like the above, we should really

I was going to quibble about using 'SHOULD' because it is so forceful, and
that a 'MAY' would suffice, but you are raising the larger question of whether
it is appropriate to have normative text at all.

I think that the real-world need is satisfied adequately while avoiding the
pitfalls of being normative, in this case:  Add advisory text that notes the
issue and describes how to resolve it.  But make a point of using no normative
text to do this.

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

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 30 Apr 2007 22:19:04 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt)
Cc: Arnt Gulbrandsen <[email-masked]>, Pete Resnick <[email-masked]>, Charles Lindsey <[email-masked]>
Sender: [email-masked]

Pete Resnick writes:
> So, now I'm beginning to get uneasy about using SHOULD/RECOMMENDED in 
> here. If we want normative language like the above, we should really 
> just remove no-fold-quote (since quoted-string is already allowed in 
> the obs- syntax).

Makes sense to me. Particularly since you can look for a long time 
before you find no-fold-quote in real message-ids. Standards are 
supposed to drop unused features as they advance, right?

> How about simply:
>
>         Note: There are contexts outside of Internet mail (specifically
>         Netnews [ref]) where message identifiers containing NO-WS-CTLs,
>         quoted-pairs, and specials on the left-hand side of the "@"
>         cause trouble for some implementations. Since messages
>         sometimes do traverse contexts, avoiding these on the left-hand
>         side of the "@" may be safest for implementations.

Or that.

But intuitively I'm more fond of aligning 2822 non-obs syntax with the 
syntax most generators use.

Arnt

Date: Mon, 30 Apr 2007 15:02:08 -0500
To: Arnt Gulbrandsen <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Compatibility wit Netnews (was I-D   ACTION:draft-resnick-2822upd-01.txt)
Cc: [email-masked], Charles Lindsey  <[email-masked]>
Sender: [email-masked]

On 4/30/07 at 9:14 PM +0200, Arnt Gulbrandsen wrote:

>Pete Resnick writes:
>>I'd rather stick with the liberal syntax for now, and maybe add a 
>>note that says, "You SHOULD be conservative in what you generate, 
>>as NO-WS-CTLs, quoted-pairs, and specials are known to cause 
>>heartburn in some environments (cf. USEFOR)."
>
>+1. Proposed text: «It is RECOMMENDED to use only A-Z, a-z, 0-9, 
>".", "." and "/" on the left-hand side, and to make the left-hand 
>side at most 64 characters long. Unusual but permitted syntax such 
>as (for example) quoted-pairs are known to cause problems in some 
>contexts.»

So, now I'm beginning to get uneasy about using SHOULD/RECOMMENDED in 
here. If we want normative language like the above, we should really 
just remove no-fold-quote (since quoted-string is already allowed in 
the obs- syntax).

How about simply:

         Note: There are contexts outside of Internet mail (specifically
         Netnews [ref]) where message identifiers containing NO-WS-CTLs,
         quoted-pairs, and specials on the left-hand side of the "@"
         cause trouble for some implementations. Since messages
         sometimes do traverse contexts, avoiding these on the left-hand
         side of the "@" may be safest for implementations.

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

Date: Mon, 30 Apr 2007 21:14:47 +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]>, Charles Lindsey <[email-masked]>
Sender: [email-masked]

Pete Resnick writes:
> I'd rather stick with the liberal syntax for now, and maybe add a note 
> that says, "You SHOULD be conservative in what you generate, as 
> NO-WS-CTLs, quoted-pairs, and specials are known to cause heartburn 
> in some environments (cf. USEFOR)."

+1. Proposed text: «It is RECOMMENDED to use only A-Z, a-z, 0-9, ".", 
"." and "/" on the left-hand side, and to make the left-hand side at 
most 64 characters long. Unusual but permitted syntax such as (for 
example) quoted-pairs are known to cause problems in some contexts.»

Arnt

Date: Mon, 30 Apr 2007 11:40:14 -0500
To: "Charles Lindsey" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: Compatibility wit Netnews  (was I-D ACTION:draft-resnick-2822upd-01.txt)
Cc: [email-masked]
Sender: [email-masked]

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

>In <[email-masked]> Frank Ellermann 
><[email-masked]> writes:
>
>>For the <msg-id> I'd like to see a syntax also working in NetNews...
>
>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. But things 
like the "dot-doubling" worry me. (For example, as it stands, all of 
the following are still legal msg-ids under USEFOR:

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

I don't think that's so much of an improvement.) I'd rather stick 
with the liberal syntax for now, and maybe add a note that says, "You 
SHOULD be conservative in what you generate, as NO-WS-CTLs, 
quoted-pairs, and specials are known to cause heartburn in some 
environments (cf. USEFOR)."

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

From: [email-masked]
Cc: [email-masked]
Date: Mon, 30 Apr 2007 07:37:26 -0700 (PDT)
Subject: Re: [2822upd] Resent-* MUSTard
To: Frank Ellermann <[email-masked]>
Sender: [email-masked]

> Hi, the following paragraphs in 2822upd-01 are incompatible with
> RFC 4406:

> ...

> RFC 4406 uses Resent-* in "automatic actions on messages", both for
> redistribution (mailing lists) and redirection (alias forwarding to 3rd
> parties).  RFC 4407 uses Resent-* not only for "strictly informational"
> purposes, it evaluates Resent-* to determine the "PRA" (its "purported
> responsible address").  RFC 4405 uses this "PRA" in an SMTP extension.

> This incompatibility was approved in an appeal.

What was approved was the publication of *experimental* documents which state
that they are incompatible with exsiting standards in the area. (See the IESG
notes in RFC 4406 and 4408.) 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!

> For various technical
> reasons I think that the "PRA" is an excessively poor emulation of the
> Return-Path, and that it's stupid to introduce an entity like the "PRA"
> at this point in time shortly after RFC 3834 closed the last loophole
> where mailbots still sent auto-responses to other addresses:  Almost
> all auto-responses are now based on the Return-Path, NDRs, DSNs, MDNs,
> it makes no sense to introduce a new "PRA" sometimes resulting in the
> Sender-address which should never be used for auto-responses.

> BUT.  But while I hate the "PRA" it is not for the formal reason that
> it is incompatible with 2822.  In fact I think 2822upd should fix this
> issue.

Then you need to make a very compelling argument for the change that doesn't
depend in any way on the fact these experiments were published. Experiments,
formal or otherwise, come and go. A select few result in significant change,
many pass by largely unnoticed, and some evaporate leaving only a very bad
smell behind.

It would be nothing short of utter folly to base the development of standards
on the publication of intentionally incompatible experimental documents. It
might arguably make sense to alter tnings based on the *outcome* of an
experiment, but probably not as part of what's supposed to be a simple document
cleanup effort.

On a side note, the main reason I opposed the publication of these experiments
is because they did not even consider the issue of how to assess their own
results. Had this issue been considered I don't see how the inherent semantic
conflists between the two could have been allowed to stand.

> For starters anything wishing to go to "draft standard" will
> have to show in its "implementation and interoperability report" why
> there is a weird construct like the Resent-Sender at all:

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

> Who implements it ?

We have done so for years. 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.

> Why is the complete
> Resent-nightmare not supported in RFC 4409 8.1 "may add sender" ?

I actually see this as more of a a bug in RFC 4409 than anything else.

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

but regardless of my own take on the resent- issue, any case for this sort of
change needs to be made on its own merit. It cannot be based on name-calling
and incompatilbity with experimental documents which were known at the time
they were approved to be at odds with both existing email infrastructure and
each other.

				Ned

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

Hi, the following paragraphs in 2822upd-01 are incompatible with
RFC 4406:

   Resent fields are used to identify a message as having been
   reintroduced into the transport system by a user.  The purpose of
   using resent fields is to have the message appear to the final
   recipient as if it were sent directly by the original sender, with
   all of the original fields remaining the same.  Each set of resent
   fields correspond to a particular resending event.  That is, if a
   message is resent multiple times, each set of resent fields gives
   identifying information for each individual time.  Resent fields are
   strictly informational.  They MUST NOT be used in the normal
   processing of replies or other such automatic actions on messages.

      Note: Reintroducing a message into the transport system and using
      resent fields is a different operation from "forwarding".
      "Forwarding" has two meanings: One sense of forwarding is that a
      mail reading program can be told by a user to forward a copy of a
      message to another person, making the forwarded message the body
      of the new message.  A forwarded message in this sense does not
      appear to have come from the original sender, but is an entirely
      new message from the forwarder of the message.  On the other hand,
      forwarding is also used to mean when a mail transport program gets
      a message and forwards it on to a different destination for final
      delivery.  Resent header fields are not intended for use with
      either type of forwarding.

RFC 4406 uses Resent-* in "automatic actions on messages", both for
redistribution (mailing lists) and redirection (alias forwarding to 3rd
parties).  RFC 4407 uses Resent-* not only for "strictly informational"
purposes, it evaluates Resent-* to determine the "PRA" (its "purported
responsible address").  RFC 4405 uses this "PRA" in an SMTP extension.

This incompatibility was approved in an appeal.  For various technical
reasons I think that the "PRA" is an excessively poor emulation of the
Return-Path, and that it's stupid to introduce an entity like the "PRA"
at this point in time shortly after RFC 3834 closed the last loophole
where mailbots still sent auto-responses to other addresses:  Almost
all auto-responses are now based on the Return-Path, NDRs, DSNs, MDNs,
it makes no sense to introduce a new "PRA" sometimes resulting in the
Sender-address which should never be used for auto-responses.

BUT.  But while I hate the "PRA" it is not for the formal reason that
it is incompatible with 2822.  In fact I think 2822upd should fix this
issue.  For starters anything wishing to go to "draft standard" will
have to show in its "implementation and interoperability report" why
there is a weird construct like the Resent-Sender at all:

Who needs a Resent-Sender ?  Who implements it ?  Why is the complete
Resent-nightmare not supported in RFC 4409 8.1 "may add sender" ?  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 ?

Frank

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: Compatibility wit Netnews
Date:  Mon, 30 Apr 2007 00:50:06 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 90
Sender: [email-masked]

Charles Lindsey wrote:

 [canonical Message-ID]
> The essential feature required for Netnews was that, in order to
> compare two <mesg-id>s for equality, a simple octet-by-octet
> comparison would always suffice. Such comparisons are at the very
> heart of the Netnews protocol, though they hardly arise at all in
> email except for the purpose of threading articles in MUAs using
> the <msg-id>s that occur in References header fields. Even there,
> I suspect, many threaders have simply implemented an octet-by-octet
> comparison.

+1  And it's not only about "comparing" Message-IDs, it's also about
using something that's allowed in NNTP, i.e. no raw control char.s
(= NO-WS-CTL), and no ">" even within <no-fold-quote> (quoted LHS) or
<no-fold-literal> (domain literal as RHS).

Another application are Message-IDs in mailing list archives used as
Archived-AT URIs, or Message-IDs in NetNews used in news: URIs.  It's
possible to percent-encode any NO-WS-CTL, but it would be a pain.

Percent-encoding is always a kludge and harms interoperability as
soon as applications try to percent-encode something that is already
partially percent-encoded for local purposes, and then let another
application try to undo this.  The PURL resolver is an example how
that can get too easily out of hand.

 [magic SP]
> The other principle difference is that, in each header field, an
> SP is obligatory after the ":". Since this is already the universal
> practice within email, I would suggest that there should be no
> problem in REQUIRING the same in the case of email, and to banish
> the possibility of omitting that SP to the obs-syntax.

I'd support a mandatory FWS after the colon.  But I can't support a
"magic SP" also in mail, IMO any significant "trailing white space"
is harmful.  Let's take an example header field:

   foo = "foo:" [CFWS] bar [CFWS] CRLF

Adding a magic SP results in:

   foo = "foo:" SP [CFWS] bar [CFWS] CRLF

Now the following folding would be syntactically wrong:

| foo:<CRLF>
| <WSP>bar<CRLF>

The NetNews RFC guarantees that it's never allowed to fold a header
field before the first non-blank character in the header field body,
here <bar>.  But 2822 doesn't guarantee this, it only says that a
folded line containing _only_ trailing white space isn't allowed.

And it's okay that 2822 doesn't guarantee this, sometimes it's very
convenient to fold a header field directly at the colon.  Extremely
long 2047-encoded words are an example, it would be odd to have a
special rule for the first line of a folded header field depending
on the length of the field name.

So I'd propose to add a mandory FWS to unstructured fields and the
<date-time>, i.e. all header field bodies not starting with [CFWS].

All other header field bodies start with [CFWS], and we could make
it mandatory, for the example above:

   foo = "foo:" CFWS bar [CFWS] CRLF

A magic SP matches CFWS, you can do what you claim everybody does
already.  An initial folding also matches CFWS, theerfore I can
fold header fields directly after the colon.  Admittedly this
still allows silly constructs:

| foo:(ugh)bar<CRLF>

OTOH it's no new ugliness, 2822 already allows this.  In essence
the only ugliness allowed by 2822 which would be "eliminated" by
a mandatory CFWS is this:

| foo:bar<CRLF>

> Life would be much simpler if Email could now be brought into
> line with Netnews in these regards (the present practices would
> just move to the obs-syntax, of course).

USEFOR had compelling reasons why it didn't copy all 2822 ideas.
I think the opposite is also true.

Frank

To: [email-masked]
Xref: clerew local.mime:4974
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: draft-resnick-2822upd-01 posted
Date: Fri, 27 Apr 2007 19:05:53 GMT
Lines: 24
Sender: [email-masked]

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

>You may have noticed that 2822upd-01 was posted.

>Though overall very few, there are real changes from 2822 in this 
>document that need review. See the changes section at the bottom. I 
>did *not* go whole hog and switch to Bruce's syntax, simply because I 
>wanted to limit the number of changes and see if we can't get this 
>thing to Draft along with 2821bis.

I think it is a great pity that you did not go that whole hog, since
Bruce's syntax was a great improvement on the present syntax, which can be
exceedingly hard to follow in many obscure situations.

-- 
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:4973
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Compatibility wit Netnews (was I-D ACTION:draft-resnick-2822upd-01.txt)
Date: Fri, 27 Apr 2007 19:02:54 GMT
Lines: 58
Sender: [email-masked]

In <[email-masked]> Frank Ellermann <[email-masked]> writes:

>[email-masked] wrote:

>> http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt

>For the <msg-id> I'd like to see a syntax also working in NetNews,
>in news URIs, and in Archived-At links when they use a Message-ID.

>A "canonical" version of a Message-ID is specified in
>RFC.ietf-usefor-usefor-12

Indeed, the Message-ID is the principal feature of RFC 2822 which could
not be incorporated into Netnews as it stood. Draft-ietf-usefor-usefor-12,
which has now been approved by the IESG, but is likely to remain in the
RFC Editor's queue until other documents referenced by it are ready for
publication, made the minimum change to <msg-id> (essentially reducing it
to a canonicalized form) that would work. That is essentially what Frank
has described, but there are other alternative possibilities involving
further restrictions which might result in a cleaner syntax.

The essential feature required for Netnews was that, in order to compare
two <mesg-id>s for equality, a simple octet-by-octet comparison would
always suffice. Such comparisons are at the very heart of the Netnews
protocol, though they hardly arise at all in email except for the purpose
of threading articles in MUAs using the <msg-id>s that occur in References
header fields. Even there, I suspect, many threaders have simply
implemented an octet-by-octet comparison.

The other principle difference is that, in each header field, an SP is
obligatory after the ":". Since this is already the universal practice
within email, I would suggest that there should be no problem in REQUIRING
the same in the case of email, and to banish the possibility of omitting
that SP to the obs-syntax.

Other differences are the omission of <comment>s in a few places (notably
Message-ID), a requirement for WSP between each <msg-id> in a References
header field (too many current threaders expect to find it there), and
requiring some non-WSP in the body of the first line of a folded header
field (this is a consequence of requiring that SP after the ":").

Life would be much simpler if Email could now be brought into line with
Netnews in these regards (the present practices would just move to the
obs-syntax, of course).

As a separate issue, it might be as well to review the whole of the
contents of the obs-syntax, but that is a matter for a separate discussion.

-- 
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: Thu, 26 Apr 2007 23:22:15 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: draft-resnick-2822upd-01 posted
Sender: [email-masked]

On 4/26/07 at 4:55 PM -0500, I Resnick wrote:

>You may have noticed that 2822upd-01 was posted.
>
><http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt>
>Also:
><http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.html>
><http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.xml>
><http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.txt>

To make rfcdiff work, I've put a copy of RFC 2822 on my web site with 
some of the later sections rearranged so that they're in the same 
order as the current draft. You can see the diffs between the two 
here:

<http://tools.ietf.org/rfcdiff?url1=http://www.qualcomm.com/~presnick/rfc2822-fixed.txt&url2=http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt>

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

To: [email-masked]
From: Frank Ellermann <[email-masked]>
Subject:  Re: I-D ACTION:draft-resnick-2822upd-01.txt
Date:  Fri, 27 Apr 2007 00:33:44 +0200
Organization:  <URL:http://purl.net/xyzzy>
Lines: 113
Sender: [email-masked]

[email-masked] wrote:

> http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt

Hi, where's that discussed, is here okay ?

For the <msg-id> I'd like to see a syntax also working in NetNews,
in news URIs, and in Archived-At links when they use a Message-ID.

A "canonical" version of a Message-ID is specified in
RFC.ietf-usefor-usefor-12

It has the following features:

- once created a Message-ID is "opaque", nobody's supposed to
  modify its id-right, even if that's a FQDN as it should be,
  where modifying say mixed case to lower case is tempting.
- Message-ID generators shouldn't use <quoted-pair>s unless they
  must.
- There is no NO-WS-CTL in a Message-ID.

Based on these concepts a "canonical" Message-ID is something like
this:

   msg-id          =  "<" msg-id-core ">"
                      ; maximum length is 250 octets

The maximum length is for NetNews and NNTP, and maybe this limit
is irrelevant for mail.  OTOH mail2news would be forced to reject
or discard any longer Message-ID if they can't guarantee that all
gateways have precisely the same idea how to truncate it.

   msg-id-core     =  id-left "@" id-right

That's handy for other header fields like References in a NetNews
RFC, or in a draft about news URLs, maybe it's unnecesary for mail.

   id-left         =  dot-atom-text / no-fold-quote

The 2822upd draft adds <obs-id-left> as in 2822, for NetNews the
obs-* terms (with two exceptions) aren't used.

   id-right        =  dot-atom-text / no-fold-literal

Same idea, 2822upd needs also <obs-id-right> for its purposes.

   no-fold-quote   =  DQUOTE
                         ( "." *mqtext /
                           *mqtext "." /
                           *mqtext mqspecial *mqtext )
                      DQUOTE

Major difference, 2822upd allows in essence any qtext or quoted-pair.
RFC.ietf-usefor-usefor-12 limits <no-fold-quote> to the three cases
where it's required:

1: "." *mqtext  \/  Something starting or ending with a dot is never
2: *mqtext "."  /\  a <dot-atom-text>, therefore it must be quoted

3: *mqtext mqspecial *mqtext

All <mqspecial> constructs aren't allowed in <dot-atom-text>, same
idea as for the leading or trailing dot issues (1) + (2).

   mqtext          =  atext / "." / mqspecial

One reason forcing a <no-fold-quote> is enough.  Anything else can
either as is <dot-atom-text>, i.e. <atext> or ".", or as in the
<mqspecial> constructs:

   mqspecial       =  "(" / ")" /      ; same as specials except
                      "<" /            ; "\" and DQUOTE quoted
                      "[" / "]" /      ; "." doubled and ">" omitted
                      ":" / ";" /
                      "@" / "," /
                      ".." / "\\" / "\" DQUOTE

<mqspecial> is a collection of characters not covered by <atext>,
plus '\\' and '\"' as the two <quoted-pair>s needed in the left
hand side <id-left> for a <no-fold-quote>.  Last but not least it
also covers adjacent dots, that's not allowed in a <dot-atom-text>.

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

Major difference, 2822upd allows in essence any dtext or quoted-pair.
RFC.ietf-usefor-usefor-12 limits <no-fold-literal> to the one case
where it's required:

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

That's not the same as <dtext>, it has obviously no NO-WS-CTL.  The
business about the three '\[', '\]', and '\\' <quoted-pair>s is the
same as in 2822 or 2822upd.  No other <quoted-pair>s are required
in the <no-fold-literal> form of the <id-right>.

For its own purposes RFC.ietf-usefor-usefor-12 decrees that a '>'
must never occur within a <msg-id> or rather <msg-id-core> because
that would break NNTP and other news servers and clients.  It's
fortunately no issue for news URIs, where '>' is anyway not allowed
(and if somebody tries %3E or similar they get what they asked for).

I'd like if the one thing that's essential NetNews, the Message-ID,
has the same syntax everywhere.  We're talking about rare corner
cases like domain literals and quoted strings as local parts in a
Message-ID, <no-fold-literal> and <no-fold-quote>.  As far as these
constructs are anywhere used at all they don't need ugly NO-WS-CTLs
or unnecessary quoted pairs.  I'd also doubt that such constructs
survive a serious 2822 implementation and interoperability report.

Frank

Date: Thu, 26 Apr 2007 16:55:06 -0500
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: draft-resnick-2822upd-01 posted
Sender: [email-masked]

You may have noticed that 2822upd-01 was posted.

<http://www.ietf.org/internet-drafts/draft-resnick-2822upd-01.txt>
Also:
<http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.html>
<http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.xml>
<http://www.qualcomm.com/~presnick/draft-resnick-2822upd-01.txt>

Though overall very few, there are real changes from 2822 in this 
document that need review. See the changes section at the bottom. I 
did *not* go whole hog and switch to Bruce's syntax, simply because I 
wanted to limit the number of changes and see if we can't get this 
thing to Draft along with 2821bis. But I did incorporate (hopefully 
all of) the corrections that you all have pointed out over the last 
couple of years.

Please review with a fine toothed comb. If there are more than just a 
few problems, perhaps I'll ask Tony Hansen or Philip Guenther (who 
have at assorted time offered assistance) to start an issues list.

Thanks in advance for your assistance.

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

Date: Tue, 24 Apr 2007 10:42:05 +0200
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: 2822bis and ""@example.org
Cc: Bruce Lilly <[email-masked]>
Sender: [email-masked]

Bruce Lilly writes:
> ""@[]
>
> is also valid, as discussed here some time ago (beginning September 
> 30, 2002).
> I seem to recall that you participated in that discussion...

You're perfectly right, and upon rereading the thread, my opinion seems 
a sensible one. On the whole, though, I found this posting from you 
persuasive:
http://www.imc.org/ietf-822/mail-archive/msg02502.html
and I'm sorry I did not say so at the time.

Arnt

From: Bruce Lilly <[email-masked]>
Reply-To: ietf-822 <[email-masked]>
Organization: Bruce Lilly
To: ietf-822 <[email-masked]>
Subject: Re: 2822bis and ""@example.org
Date: Mon, 23 Apr 2007 22:11:49 -0400
Cc: Arnt Gulbrandsen <[email-masked]>
Sender: [email-masked]

On 2007-03-28, Arnt Gulbrandsen wrote:
> 
> In 2822 that address is apparently valid. Should that be so?
> 
> I could understand it being a valid obs-this-or-that address. But it 
> seems to be quite simply valid. Message parsers must parse it, messages 
> senders may generate it.

""@[]

is also valid, as discussed here some time ago (beginning September 30, 2002).
I seem to recall that you participated in that discussion...