Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
From: Tony Finch <[email-masked]>
To: Dave Crocker <[email-masked]>
Cc: Pete Resnick <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Thu, 6 Dec 2007 15:17:18 +0000
List-Id: <ietf-822.imc.org>

On Wed, 5 Dec 2007, Dave Crocker wrote:
>
> How would you describe what they do do?

Sendmail and (recent versions of) Postfix never add a Sender: field to the
header. Exim (by default) adds a Sender: field corresponding to the
authenticated sender if this is different from the From: field, which is
what 822 and 2822 and 4409 suggest. Traditional Unix MUAs don't bother
showing the Sender: field, but Microsoft Outlook is quite keen on it.
Therefore in our environment messages from role addresses tend to show up
in Outlook as "from person on behalf of role" which is annoying. I'm
inclined to give up on adding Sender: fields as specified and instead use
non-standard annotations in the Received: fields to record the
authenticated sender (as in this message).

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FITZROY SOLE LUNDY FASTNET: WESTERLY 7 TO SEVERE GALE 9, PERHAPS STORM 10
LATER IN SOLE, LUNDY AND FASTNET. ROUGH OR VERY ROUGH, OCCASIONALLY HIGH. RAIN
THEN SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR.

Date: Wed, 05 Dec 2007 16:29:31 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Dave Crocker <[email-masked]>
CC: Tony Finch <[email-masked]>, Pete Resnick <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Sender: [email-masked]

Dave Crocker wrote:
> 
> 
> Tony Finch wrote:
>>>      "The "Sender:" field specifies the
>>>    mailbox of the agent responsible for the actual transmission of the
>>>    message."
>>
>> Popular MTA implementations (Sendmail, Postfix) do not implement the
>> Sender: header the way 822 and 2822 suggest,
> 
> How would you describe what they do do?

Well, if SendMail/PostFix is operating like the rest of the world... If 
missing, a SMTP receiver MIGHT do:

    Sender: <-- x821.MailFrom

in the same vain many SMTP receivers will fill in the missing 822 
required fields.

    FROM:  <<-- x821.MailFrom
    To:    <<-- x821.RcptTo

and they MUST do this if they want to SUPPORT the presentation layers.

But sender is not a given because it is not a 822 required field. In 
fact, I seem to recall, it was only in recent years that we even 
bothered with Sender in our mailers.

Only a few sites will reject such empty headers in the DATA block. Off 
hand, I know of one, HOTMAIL.COM and they only started to reject mail 
without the headers when SENDER-ID support was added to HOTMAIL.COM.

-- 
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Date: Wed, 05 Dec 2007 16:14:38 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Steve Dorner <[email-masked]>
CC: [email-masked], Pete Resnick <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Sender: [email-masked]

Ha! Yammer-To-Author! Hilarious!

Thanks for making my day. :-)

-- 
Hector Santos, CTO
http://www.santronics.com

Steve Dorner wrote:
> 
> At 9:14 AM -0800 12/5/07, Dave Crocker wrote:
>> Frankly I think [Resent-] should be deprecated, because it causes so 
>> much trouble.
> 
> Along with From, Sender, and Reply-To.  :-)
> 
> I see no straightening out of the tangle we are in regarding all these 
> fields.  We keep trying to tweak the rules, tweak compliance, etc, so 
> that we get a system where everybody can conveniently do what they want, 
> and I don't think it's possible.
> 
> Frankly, I think we either just give it up and live with it, or define 
> entirely new fields with narrow, specific meanings that enable agents to 
> put together the operations we like.
> 
> Eg, deprecate (softly and over time) Sender, and replace with:
> 
> Original-Injector:
> List-Injector:
> Translated-Injector:
> Fuelled-Injector:
> ...
> 
> Deprecate Reply-To:, and replace with:
> 
> Yammer-To-Author:
> Yammer-To-List:
> Yammer-To-Mother-In-Law-of-Cousin-Of-Mailing-List-Owner:
> ...
> 
> We have to get very specific about labelling who did what to whom if we 
> hope to have a situation that is satisfying to our sense of the right 
> progression of the universe.
> 
> Some of these fields probably would need to be multiple, and even 
> order-maintained.  They might need syntax above and beyond what is 
> currently allowed for recipient fields.  There would probably be a fair 
> number of them.
> 
> But there's so much useless junk flying around in email now, several 
> dozen more addressing fields would hardly be noticed.  :-)
> 
> My guess is that "living with it" is going to win.
> 
> 
> 

Date: Wed, 05 Dec 2007 13:14:24 -0800
From: Dave Crocker <[email-masked]>
Organization: Brandenburg InternetWorking
To: Tony Finch <[email-masked]>
CC: Pete Resnick <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Sender: [email-masked]

Tony Finch wrote:
>>      "The "Sender:" field specifies the
>>    mailbox of the agent responsible for the actual transmission of the
>>    message."
> 
> Popular MTA implementations (Sendmail, Postfix) do not implement the
> Sender: header the way 822 and 2822 suggest,

How would you describe what they do do?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 5 Dec 2007 11:55:28 -0800
To: [email-masked]
From: Steve Dorner <[email-masked]>
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Cc: Pete Resnick <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 9:14 AM -0800 12/5/07, Dave Crocker wrote:
>Frankly I think [Resent-] should be deprecated, because it causes so 
>much trouble.

Along with From, Sender, and Reply-To.  :-)

I see no straightening out of the tangle we are in regarding all 
these fields.  We keep trying to tweak the rules, tweak compliance, 
etc, so that we get a system where everybody can conveniently do what 
they want, and I don't think it's possible.

Frankly, I think we either just give it up and live with it, or 
define entirely new fields with narrow, specific meanings that enable 
agents to put together the operations we like.

Eg, deprecate (softly and over time) Sender, and replace with:

Original-Injector:
List-Injector:
Translated-Injector:
Fuelled-Injector:
...

Deprecate Reply-To:, and replace with:

Yammer-To-Author:
Yammer-To-List:
Yammer-To-Mother-In-Law-of-Cousin-Of-Mailing-List-Owner:
...

We have to get very specific about labelling who did what to whom if 
we hope to have a situation that is satisfying to our sense of the 
right progression of the universe.

Some of these fields probably would need to be multiple, and even 
order-maintained.  They might need syntax above and beyond what is 
currently allowed for recipient fields.  There would probably be a 
fair number of them.

But there's so much useless junk flying around in email now, several 
dozen more addressing fields would hardly be noticed.  :-)

My guess is that "living with it" is going to win.

Date: Wed, 5 Dec 2007 19:53:20 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: Pete Resnick <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Sender: [email-masked]

On Wed, 5 Dec 2007, Dave Crocker wrote:
>
> Well, let's get back to first princples.  RFC 2822 3.6.2:
>
>      "The "Sender:" field specifies the
>    mailbox of the agent responsible for the actual transmission of the
>    message."

Popular MTA implementations (Sendmail, Postfix) do not implement the
Sender: header the way 822 and 2822 suggest, so even before you consider
mailing list managers you need to be very careful about RFC lawyering.

Microsoft MUAs present message headers in a way that works best if normal
messages do not have a Sender: field and mailing list messages do have one.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
LUNDY FASTNET IRISH SEA SHANNON: WEST OR SOUTHWEST 6 TO GALE 8, PERHAPS SEVERE
GALE 9 LATER. HIGH OR VERY HIGH IN FASTNET AND SHANNON, ROUGH OR VERY ROUGH IN
LUNDY AND IRISH SEA. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY
POOR.

Date: Wed, 5 Dec 2007 19:44:12 +0000
From: Tony Finch <[email-masked]>
To: [email-masked]
cc: Pete Resnick <[email-masked]>, John Levine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Sender: [email-masked]

On Tue, 4 Dec 2007, [email-masked] wrote:
>
> I don't recall anyone considering using Resent- fields for this until
> just now, but I could easily have missed it

I think it's a cute idea, but Resent- fields are an interop nightmare
because the 822 specification is too weak to work in general (e.g. a
sequence of multiple resendings) and the 2822 specification is not
entirely compatible and not widely implemented.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: CYCLONIC 5 TO 7, OCCASIONALLY GALE 8 AT FIRST IN SOUTH.
ROUGH OR VERY ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.

Date: Wed, 5 Dec 2007 19:38:38 +0000
From: Tony Finch <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: Handling of NO-WS-CTL in 2822bis
Sender: [email-masked]

On Tue, 4 Dec 2007, Pete Resnick wrote:

> (Question: Should they contain NUL as well?)

IMAP forbids NULs, so I would suggest not permitting them in any new obs-
variant of syntax that does not allow them in 2822.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOLE: WEST OR SOUTHWEST 5 TO 7 INCREASING GALE 8. VERY ROUGH OR HIGH. RAIN.
MODERATE OR POOR.

Date: Wed, 05 Dec 2007 09:14:37 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: Pete Resnick <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Sender: [email-masked]

Pete Resnick wrote:
> On 12/1/07 at 3:30 PM +0000, John Levine wrote:
>> RFC 2822 section 3.6.2 describes originator fields.  By my reading it 
>> is pretty clear that a list should add a Sender: field with the list's 
>> name since it's the list that's sending the mail.
> 
> Uh.....not by my reading. Lists add List-* fields (RFC 2369, RFC 2919) 
> if they want to indicate something. Fields in the original message 
> should be preserved as-is.

Well, let's get back to first princples.  RFC 2822 3.6.2:

      "The "Sender:" field specifies the
    mailbox of the agent responsible for the actual transmission of the
    message."

Is a message fully delivered to a mailing list processor, or is the mailing
list processor merely an odd kind of MTA?  I think there is no controversy
that it is fully delivered, with respect to the mail handling service.  This
means that the mailing list does indeed then "post" the message (back) into
the message stream. In the abstract, then, each posting is for a "new" message.

However...

Perhaps the new posting is really exactly the same as the original message,
except for the addressee list, so that the original Sender field value is
semantically valid?  To me, this has the benefit of being the most relevant
question and the detriment of being pretty subjective.  But then, email
identity strings involve a fair amount of subjectivity already, so it's
probably no major burden to have this one (too.)

Perhaps the mailing list has made significant changes to the message.
Certainly taking multiple messages, to produce a digest, qualifies but I think
other changes do, too.  Where is the limit?  I have no idea.  Since the
mailing list and the original author have a cooperative arrangement, I'm happy
to let them decide.

But the key point is that it means that retaining or replacing the Sender 
value is not a rigid decision.  In other words, it *is* a decision that the 
mailing list operator needs to make explicitly, but the choice entirely 
depends upon the amount of violence that list software does to messages it 
re-posts.

As you (Pete) said in a separate conversation, the underlying question is what 
the Sender address needs to be used for and what will serve that need best.

I don't know that we have much culture around legitimate use of that value, by 
receivers or downstream handlers.

>> Section 3.6.6 describes resent headers.  One could make a plausible 
>> argument that a list should add a Resent-Sender: rather than a Sender: 
>> but it's reasonable to do it either way.
> 
> Mailing lists using Resent-* fields gives me the willies. Resent-* 
> fields were intended for MUAs resending mail. They weren't intended for 
> mailing lists.

Resent was an entirely reasonable idea, but it is one that proved far more
problematic than beneficial.  It works from a simplistic model that seemed 
like a wonderful idea at the time and, IMO, has since shown to merely add 
confusion and complexity rather than benefit.

Frankly I think it should be deprecated, because it causes so much trouble.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Wed, 5 Dec 2007 08:10:04 -0800
From: Philip Guenther <[email-masked]>
To: Pete Resnick <[email-masked]>
cc: [email-masked]
Subject: Re: Handling of NO-WS-CTL in 2822bis
Sender: [email-masked]

On Tue, 4 Dec 2007, Pete Resnick wrote:
> Let me explain what is involved in doing this. If people are OK with this, 
> I'll go ahead. To remove NO-WS-CTL, we need to:
>
> - Remove NO-WS-CTL from ctext, qtext, utext, and dtext. (That makes utext 
> simply VCHAR.)
> - Create obs-ctext, obs-qtext, and obs-dtext which contain NO-WS-CTL. 
> (Question: Should they contain NUL as well?)
> - Add NO-WS-CTL to obs-utext.
> - Change quoted-pair to use "WS / VCHAR" instead of "text".
> - Change section 2.2 to say that header fields only contain VCHARs.
> - Change much of the text in the beginning of section 4 to add talk of 
> NO-WS-CTL.

The above looks correct and minimal to me.

> Is everyone sure they want to do this? Do we think this will recycle at 
> Proposed? It is effectively removing what we think is an unused feature from 
> the document in anticipation of Draft, but it is a significant textual 
> change.

Yes and yes.

Philip Guenther

Date: Tue, 04 Dec 2007 20:16:29 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Pete Resnick <[email-masked]>
CC: John Levine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Sender: [email-masked]

Pete Resnick wrote:
> 
> [Apologies for duplicates, if any. List issues and decided to Cc 
> ietf-822 and ietf-smtp.]
> 
> On 12/1/07 at 3:30 PM +0000, John Levine wrote:
> 
>> RFC 2822 section 3.6.2 describes originator fields.  By my reading it 
>> is pretty clear that a list should add a Sender: field with the list's 
>> name since it's the list that's sending the mail.
> 
> Uh.....not by my reading. Lists add List-* fields (RFC 2369, RFC 2919) 
> if they want to indicate something. Fields in the original message 
> should be preserved as-is.

Unfortunately, that is not the common practice by many MLS (Mail List 
Server) systems.

Both Sender: and Reply-To: are quite often changed.

The practice is to match the Sender with the Return-path or more 
specifically who was the x821.Mail From address.  That why it works for 
MUA users in the first place and naturally falls in line when a mailing 
list owner redistributed the mail.

The problem of course, we have complicated the 1 to 1 email system into 
a 1 to Many group ware, conferencing system and there are all kinds of 
considerations here.  It is not a simple CC concept and its not a old 
school SMTP level group list forwarding concept where we don't have a 
full blown, feature rich separate but integrated List Server products 
out there.

You also have the school of thought that once an "Conference Message", 
and that is what it really is, reaches the final destination/delivery, 
only the message and TO: FROM: SUBJECT and DATE: is "copyrighted" by the 
user. The transparent network control header trace lines are no longer 
his business.  That is a long time deeply held practice across different 
mail networks.

But if the concern is the Sender: header will be replaced a MLS, thats 
really a small potato in the big barrel of many other common MLS common 
optional offerings:

    - Sender: replacement
    - Reply-To:
    - MIME, HTML, Attachments stripping
    - Footers and quite possibly headers
    - Message Wrapping with HTML FRAME, IF RAME or DIV tags
    - Digest Consolations

what else?

To me, DKIM needs to conform with what exist. Not the other way around. 
  Of course, we can make changes to our MLS systems to help make DKIM 
work better, but the idea that we will be eliminating long establish 
ideas like above, is probably a little unrealistic, not going to happen.

The better idea is for the new system (DKIM signer) to have better 
knowledge of where it is sending its mail and do not sign headers that 
are very likely to change.  This is indicated in RFC 4871 as one of many 
possible strategies in deciding which headers to sign.  Thats the more 
realistic approach to this issue.

Of course, my opinion.

-- 
Hector Santos, CTO
http://www.santronics.com

From: [email-masked]
Cc: John Levine <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Tue, 04 Dec 2007 16:27:55 -0800 (PST)
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
To: Pete Resnick <[email-masked]>
Sender: [email-masked]

> [Apologies for duplicates, if any. List issues and decided to Cc
> ietf-822 and ietf-smtp.]

> On 12/1/07 at 3:30 PM +0000, John Levine wrote:

> > RFC 2822 section 3.6.2 describes originator fields.  By my reading
> > it is pretty clear that a list should add a Sender: field with the
> > list's name since it's the list that's sending the mail.

> Uh.....not by my reading. Lists add List-* fields (RFC 2369, RFC
> 2919) if they want to indicate something. Fields in the original
> message should be preserved as-is.

> > Section 3.6.6 describes resent headers.  One could make a plausible
> > argument that a list should add a Resent-Sender: rather than a
> > Sender: but it's reasonable to do it either way.

> Mailing lists using Resent-* fields gives me the willies. Resent-*
> fields were intended for MUAs resending mail. They weren't intended
> for mailing lists.

Rathole alert.

The question of what mailing lists should or should not do to message headers
in general and originator fields in particular has been one of the most hotly
debated topics in email over the years, and I've seen no indication that any
consensus has formed around a particular position.

The working that was chartered some years back to attempt to deal with this
self-destructed.

Plenty of people (like Pete, apparently) believe that mailing lists should not
mess around with originator headers at all, ever. There was a time when this
position was so prevalent that the operators of mailing list expanders
routinely got flamed for operating in any other way.

Others believe that it is perfectly OK for mailing lists to insert Sender:
fields. There's even a school of thought that says a From: should be inserted
(haven't seen too many proponents of that one since 2822 came out, but it may
still exist).

I don't recall anyone considering using Resent- fields for this until just now,
but I could easily have missed it - these debates frequently have descended
into nasty personal attacks, causing me to tune out.

Speaking as an implementor of mailing list software, I've long since given up
trying to tell people how this should be configured. As a result our software
lets people do whatever they want in this regard. And that's exactly what
people do - whatever they want.

My personal opinion is that a rule either way on originator field issue would
be better than the current situation. But I also think it is unlikely that
consensus can be reached on one.

				Ned

Date: Tue, 4 Dec 2007 15:52:16 -0800
To: John Levine <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

[Apologies for duplicates, if any. List issues and decided to Cc 
ietf-822 and ietf-smtp.]

On 12/1/07 at 3:30 PM +0000, John Levine wrote:

>RFC 2822 section 3.6.2 describes originator fields.  By my reading 
>it is pretty clear that a list should add a Sender: field with the 
>list's name since it's the list that's sending the mail.

Uh.....not by my reading. Lists add List-* fields (RFC 2369, RFC 
2919) if they want to indicate something. Fields in the original 
message should be preserved as-is.

>Section 3.6.6 describes resent headers.  One could make a plausible 
>argument that a list should add a Resent-Sender: rather than a 
>Sender: but it's reasonable to do it either way.

Mailing lists using Resent-* fields gives me the willies. Resent-* 
fields were intended for MUAs resending mail. They weren't intended 
for mailing lists.

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

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: Handling of NO-WS-CTL in 2822bis
Date:  Wed, 5 Dec 2007 00:49:55 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 36
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Pete Resnick wrote:

> - Remove NO-WS-CTL from ctext, qtext, utext, and dtext.=20
>   (That makes utext simply VCHAR.)

A kind of early "seasonal" gift, utext is simply VCHAR.

No more Escape-sequence-tricks in subjects, half of the
security considerations can go to the obs-section (yes,
I know, there were no security considerations about it)

> - Create obs-ctext, obs-qtext, and obs-dtext which
>   contain NO-WS-CTL.=20

<obs-dtext> didn't exist in practice, IMO you can skip
this step.

> (Question: Should they contain NUL as well?)

Not as part of the NO-WS-CTL cleanup, NUL was already
an obs-cenity in a few places, not a NO-WS-CTL.  It's
in obs-qp (=3D> no new effect for 2822upd), obs-char,
(indirectly) in obs-text, and therefore (indirectly)
also in the existing <obs-utext>. =20

Keep NUL where it is if the "interoperabilty report"
shows that NUL is widely implemented and understood.
(But my old Netscape 3.x froze when it found a NUL)

> Do we think this will recycle at Proposed?

Obsoleting cruft is allowed.  I'm looking forward to
a justification why NUL is kept as an obs-cenity, it=20
ought to be "appeal-repelling" or something.

 Frank

Date: Tue, 04 Dec 2007 15:45:38 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked]
Subject: Re: Handling of NO-WS-CTL in 2822bis
Sender: [email-masked]

Pete Resnick wrote:
> Is everyone sure they want to do this? Do we think this will recycle at 
> Proposed? It is effectively removing what we think is an unused feature 
> from the document in anticipation of Draft, but it is a significant 
> textual change.

My understanding of what is being proposed is to *reduce* a capability.  My 
understanding of going to Draft is that removing features is allowed.

I am assuming that Pete's detailed list is merely an translation of the 
'remove' requirement into its particulars.

Since there seems to be strong agreement on the motivation for the reduction, 
and since it seems to fit within the constraints of moving to Draft, I'll add my

+1.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Tue, 4 Dec 2007 10:10:27 -0800
To: [email-masked]
From: Pete Resnick <[email-masked]>
Subject: Re: Handling of NO-WS-CTL in 2822bis
Cc: [email-masked]
Sender: [email-masked]

On 12/3/07 at 2:51 PM -0800, [email-masked] wrote:

>I believe that the best course of action is to remove NO-WS-CTL from 
>the generate syntax, leaving it in the interpret syntax. This 
>includes its use in quoted-pair/qtext, ctext, and dtext.

Let me explain what is involved in doing this. If people are OK with 
this, I'll go ahead. To remove NO-WS-CTL, we need to:

- Remove NO-WS-CTL from ctext, qtext, utext, and dtext. (That makes 
utext simply VCHAR.)
- Create obs-ctext, obs-qtext, and obs-dtext which contain NO-WS-CTL. 
(Question: Should they contain NUL as well?)
- Add NO-WS-CTL to obs-utext.
- Change quoted-pair to use "WS / VCHAR" instead of "text".
- Change section 2.2 to say that header fields only contain VCHARs.
- Change much of the text in the beginning of section 4 to add talk 
of NO-WS-CTL.

Is everyone sure they want to do this? Do we think this will recycle 
at Proposed? It is effectively removing what we think is an unused 
feature from the document in anticipation of Draft, but it is a 
significant textual change.

pr
-- 
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:5135
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: Handling of NO-WS-CTL in 2822bis
Date: Tue, 4 Dec 2007 13:59:07 GMT
Lines: 16
Sender: [email-masked]

In <[email-masked]> Tony Hansen <[email-masked]> writes:

>+1. Seems the best compromise to move forward.

+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

Date: Mon, 03 Dec 2007 19:29:47 -0500
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: Handling of NO-WS-CTL in 2822bis
Sender: [email-masked]

+1. Seems the best compromise to move forward.

	Tony Hansen
	[email-masked]

[email-masked] wrote:
> Pete asked me to post my position on this, so...
> 
> I believe that the best course of action is to remove NO-WS-CTL from
> the generate syntax, leaving it in the interpret syntax. This includes
> its use in quoted-pair/qtext, ctext, and dtext.
> 
> I think this is the right way to go because otherwise it is going to be
> tought o demonstrate interoperability moving to draft. It's especially
> important to remove it from quoted-string since those can be parts of
> addresses, but I fail to see a reason why we should retain this for
> comments or domain literals.
> 
> 				Ned
> 

From: [email-masked]
Date: Mon, 03 Dec 2007 14:51:11 -0800 (PST)
Subject: Handling of NO-WS-CTL in 2822bis
To: [email-masked]
Sender: [email-masked]

Pete asked me to post my position on this, so...

I believe that the best course of action is to remove NO-WS-CTL from
the generate syntax, leaving it in the interpret syntax. This includes
its use in quoted-pair/qtext, ctext, and dtext.

I think this is the right way to go because otherwise it is going to be
tought o demonstrate interoperability moving to draft. It's especially
important to remove it from quoted-string since those can be parts of
addresses, but I fail to see a reason why we should retain this for
comments or domain literals.

				Ned

Date: Mon, 3 Dec 2007 13:32:37 +0000
From: Tony Finch <[email-masked]>
To: Mikel Lindsaar <[email-masked]>
cc: [email-masked]
Subject: Re: Unquoted "@" in From still in the wild?
Sender: [email-masked]

On Sun, 2 Dec 2007, Mikel Lindsaar wrote:
>
> The reason they put this [bug] in is to handle a bug in Apple Mail.app
> which was not quoting the From field correctly if it contained a @
> symbol.  This has been fixed in subsequent revisions of Mail.app.

Mail.app is catastrophically bad at letting a user's syntax errors leak
through into 822 and 821 address fields. (It also retrys in the face of
a permanent syntax error, without any time limit or frequency back-off.)
Breaking your code to accommodate its lameness is foolish.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
FAEROES SOUTHEAST ICELAND: NORTHWESTERLY VEERING SOUTHEASTERLY 6 TO GALE 8,
PERHAPS SEVERE GALE 9 LATER. ROUGH OR VERY ROUGH. WINTRY SHOWERS, THEN RAIN OR
SLEET. MODERATE OR GOOD, OCCASIONALLY POOR LATER.

From: [email-masked]
Cc: [email-masked]
Date: Sun, 02 Dec 2007 07:44:27 -0800 (PST)
Subject: Re: Unquoted "@" in From still in the wild?
To: Mikel Lindsaar <[email-masked]>
Sender: [email-masked]

> Hello all,
> I am fixing up the TMail mail library for Ruby.  As part of this, I am
> incorporating the patches the Ruby on Rails guys have done to the library
> for their implementation. But I am checking each one :)

> There is a test case for an unquoted @ char in the from line.  Their
> handling was to whack "@" into the ATOM_CHARS definition.  Per RFC 2822
> 3.2.4 this is not a valid character for the ATOM set.

THat's a really terrible idea. Sooner or later anything that allows addresses
that are clearly syntactically invalid is going to run into trouble dealing
with some other agent that does enforce the rules.

> The reason they put this in is to handle a bug in Apple Mail.app which was
> not quoting the From field correctly if it contained a @ symbol.  This has
> been fixed in subsequent revisions of Mail.app.

Which was the right way to address the problem. Hacking everything else out
there in order to cater to one buggy applications is a sure path to madness.

> The problem is, that
> putting @ into ATOM_CHARS obviously breaks other test cases in the TMail
> library.

No kidding.

> My question is 2 fold:

> 1) Removing @ is the obvious simple solution to return to the RFC2822 spec
> as Apple have fixed Mail.app, but is this "bug" implemented elsewhere the
> list members know of?

There used to be some LAN email system that used addresses of the form

    a@b@c

(I'm sorry but I forget which one it was.) Occasionally one off these
addresses would leak out onto the Internet. But that's was quite some
time ago and I haven't seen anything comparable since.

I've also seen addresses of the form

   "a@b"@c

used, but of course these are syntactically valid.

>  Should I spend the time to handle it in this edge
> case in the library?

You have basically two viable choices: Treat it as the syntax error it is or
else add quotes to make it syntactically valid. Which one is appropriate is
impossible to say without knowing a lot more about the context in which this is
going to be used.

> It looks like a bit of a hack to change the parser to
> allow this and I don't want to go there if I don't _have_ to...

You definitely don't _have_ to.

> 2) Is @ actually allowed in the description area of the From field (ie:
>  From: mikel@me <[email-masked]> ) from a revision to the RFC that I am
> unaware of?

Not unless it is quoted. Stuff like

  "a@b" <a@b>

is unfortunately pretty common (unfortunate because it is udly and unnecessary
and tends to break simplistic parsers). But

  a@b <a@b>

is clearly bogus. And if you use it I predict the results are going to be wildy
variable - there are all sorts of ways to "resolve" such an error.

				Ned

Date: Sun, 2 Dec 2007 20:58:39 +1100
From: "Mikel Lindsaar" <[email-masked]>
To: [email-masked]
Subject: Unquoted "@" in From still in the wild?
Sender: [email-masked]

------=_Part_3595_22020535.1196589519873
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello all,
I am fixing up the TMail mail library for Ruby.  As part of this, I am
incorporating the patches the Ruby on Rails guys have done to the library
for their implementation. But I am checking each one :)

There is a test case for an unquoted @ char in the from line.  Their
handling was to whack "@" into the ATOM_CHARS definition.  Per RFC 2822
3.2.4 this is not a valid character for the ATOM set.

The reason they put this in is to handle a bug in Apple Mail.app which was
not quoting the From field correctly if it contained a @ symbol.  This has
been fixed in subsequent revisions of Mail.app.  The problem is, that
putting @ into ATOM_CHARS obviously breaks other test cases in the TMail
library.

My question is 2 fold:

1) Removing @ is the obvious simple solution to return to the RFC2822 spec
as Apple have fixed Mail.app, but is this "bug" implemented elsewhere the
list members know of?  Should I spend the time to handle it in this edge
case in the library?  It looks like a bit of a hack to change the parser to
allow this and I don't want to go there if I don't _have_ to...

2) Is @ actually allowed in the description area of the From field (ie:
 From: mikel@me <[email-masked]> ) from a revision to the RFC that I am
unaware of?

Thanks in advance.

Mikel

------=_Part_3595_22020535.1196589519873
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello all,<div><br class="webkit-block-placeholder"></div><div>I am fixing up the TMail mail library for Ruby. &nbsp;As part of this, I am incorporating the patches the Ruby on Rails guys have done to the library for their implementation. But I am checking each one :)
</div><div><br class="webkit-block-placeholder"></div><div>There is a test case for an unquoted @ char in the from line. &nbsp;Their handling was to whack &quot;@&quot; into the ATOM_CHARS definition. &nbsp;Per RFC 2822 3.2.4 this is not a valid character for the ATOM set.
</div><div><br class="webkit-block-placeholder"></div><div>The reason they put this in is to handle a bug in Apple Mail.app which was not quoting the From field correctly if it contained a @ symbol. &nbsp;This has been fixed in subsequent revisions of 
Mail.app. &nbsp;The problem is, that putting @ into ATOM_CHARS obviously breaks other test cases in the TMail library.</div><div><br class="webkit-block-placeholder"></div><div>My question is 2 fold:</div><div><br class="webkit-block-placeholder">
</div><div>1) Removing @ is the obvious simple solution to return to the RFC2822 spec as Apple have fixed Mail.app, but is this &quot;bug&quot; implemented elsewhere the list members know of? &nbsp;Should I spend the time to handle it in this edge case in the library? &nbsp;It looks like a bit of a hack to change the parser to allow this and I don&#39;t want to go there if I don&#39;t _have_ to...
</div><div><br class="webkit-block-placeholder"></div><div>2) Is @ actually allowed in the description area of the From field (ie: &nbsp;From: mikel@me &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; ) from a revision to the RFC that I am unaware of?
</div><div><br class="webkit-block-placeholder"></div><div>Thanks in advance.</div><div><br class="webkit-block-placeholder"></div><div>Mikel</div><div><br class="webkit-block-placeholder"></div>

------=_Part_3595_22020535.1196589519873--

Date: Sat, 01 Dec 2007 08:56:51 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: Frank Ellermann <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [ietf-dkim] Mailing lists as 2822-Sender
Sender: [email-masked]

Frank Ellermann wrote:
> Scott Kitterman wrote on the DKIM list:
> 
>> On Thursday 29 November 2007 06:32, Charles Lindsey wrote:
>>> Note that a mailng list expander is supposed to insert a Sender.
>  
>> IIRC it's a SHOULD and not a MUST, so one really can't rely on it.
> 
> Can you (Charles + Scott, or anybody else who knows it) please
> check this ?  I thought that mailing lists are NOT supposed to
> insert Sender (or Resent-*) header fields unless they wish to 
> participate in PRA checks (RFC 4406).

Sender predates PRA so how can PRA regulate it?

> Example:  Charles + Scott as authors (2822-From) post an answer
> to a mailing list (with 2822-Sender Scott), what's the mailing
> list software supposed to do if it doesn't support a 4406 PRA ?
> 
>  Frank (cc rfc822, maybe it's not exactly a DKIM question)

Unless I am mis-understanding here, if so, I apologize for jumping in ....

No,  for a mailing list, Sender: is generally the mailing list's "Pseudo 
Admin Agent",  like for this list IETF-DKIM message:

     Sender: [email-masked]

or like in our setup in our support lists:

     Sender: [email-masked]

So Scott should not be in the Sender: field.

The key thing is that it should never be part of a HUMAN reply process, 
and as far I recall in our various MUA testing, none include it in a 
"Reply To All" concept.  IMO, this is one reason why the PRA algorithm 
is flawed.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com