Subject: Re: I-D Action:draft-crocker-email-arch-10.txt
From: "Frank Ellermann" <[email-masked]>
To: [email-masked]
Date: Mon, 25 Feb 2008 06:53:24 +0100
List-Id: <ietf-822.imc.org>

<[email-masked]> wrote:
 
> Title           : Internet Mail Architecture
> Author(s)       : D. Crocker
> Filename        : draft-crocker-email-arch-10.txt

===
In the Message-ID chapter:

| If a message is included in a digest of messages, it the digest
| constitutes a new message.

s/it//

===
| If a message is "redirected", such as using RFC2822 "Redirect-*"
| headers, some recipients will consider it the same message, but
| some will not.

That's about s/Redirect-* header/Resent-* header fields/
 
2822upd-06 offers a SHOULD for Resent-Message-ID, what excuse do
the "some" have to add no Resent-Message-ID, RFC 822 ?

===
Table 4.1.4:

Sender set by source, so far it's clear.  Then I'd expect that
To/Cc/Bcc are also set by the source, not by the author.  

Ditto and more important Rcpt-To is not set by the author, but
by the source (or mediator).  Mail-From set by source is clear,
but Mail-From can be also set by the mediator, e.g., by a list,
or in the "Resent-*" cases.

The table would be clearer with "indicates" instead of "set by",
e.g., a Reply-To might be "set by" the source (sender) secy@, 
but it "indicates" the preferred reply address of the author...
hopefully, otherwise secy@ has a problem with boss@

===
| notifications Return addresses

An "envelope sender address" is the term used in the DSN draft
standards, maybe "also known as envelope sender address" helps.

===
"Helo/Ehlo set by source":  The table states "set by latest
relay client", IMO the table is correct, not set by the source.

===
| The name of this field is misleading, because it is not
| required to specify either the author or the agent Actor
| responsible for submitting the message.  Rather, the agent
| Actor responsible for submission specifies the 
| RFC2821.MailFrom address.

After ignoring the reverse-path routing cruft it is supposed to
be an "envelope sender address" (see above) dealing with error
notifications and other auto-replies.  The envelope sender is
"responsible" for submitting the message (wrt SMTP), IMO that's
the definition.  

In other words, responsible is either the source or a mediator.
The latter is apparently explained in chapter 5, so I guess for
chapter 4 only source is as it should be.

===
For chapter 5.2 Resent-Message-ID could be also interesting.

 Frank 

  

Date: Tue, 12 Feb 2008 15:03:51 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: 2822upd-06 submitted
Sender: [email-masked]

Charles Lindsey writes:
> Maybe, but that could be a long time a-coming.
>
> Surely it is better to include a non-normative NOTE to cover issues 
> like this, where one wishes to discourage 'stupid' behaviour 
> (especially where it might cause interoperability with other 
> protocols), but where there are good reasons (as here) not to go so 
> far as a SHOULD NOT.

Put differently: "Since noone could be foolish enough to volunteer as 
editor for such a document, Pete should do it as non-normative notes in 
2822upd". My name isn't Pete so I rather like the idea, but I don't 
dare suggest it to him ;)

Arnt

To: [email-masked]
Xref: clerew local.mime:5294
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: 2822upd-06 submitted
Date: Tue, 12 Feb 2008 11:38:47 GMT
Lines: 36
Sender: [email-masked]

In <[email-masked]> Arnt Gulbrandsen <[email-masked]> writes:

>My position (at the end of a longish offline thread) is that

>1. Sending anything other than colon-space is stupid. I know - I used an 
>MTA that did it for years. People write careless perl scripts to 
>process mail and colon-tab or just-colon gives those scripts 
>indigestion.

>2. Some people do it (even after careful thought) and 2822-upd is not 
>the kind of document that should render thoughtful, compliant 
>implementations non-compliant.

>I'd like to see a new document that says "here's what you shouldn't do, 
>even though 822 and its successors have allowed it for decades, and 
>even though some people like to do it". (colon-space, multi-address 
>from, etc.) But such a document has to start at PS. 2822-upd isn't that 
>document.

Maybe, but that could be a long time a-coming.

Surely it is better to include a non-normative NOTE to cover issues like
this, where one wishes to discourage 'stupid' behaviour (especially where
it might cause interoperability with other protocols), but where there are
good reasons (as here) not to go so far as a SHOULD NOT.

-- 
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, 11 Feb 2008 15:22:42 -0800
To: Tony Hansen <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: 2822upd-06 submitted
Cc: [email-masked]
Sender: [email-masked]

On 2/11/08 at 4:00 PM -0600, Tony Hansen wrote:

>...after consultation with Pete, we're going to move forward with 
>the current version of the doc into IETF last call.

Which means that those simple editorial comments brought up since -06 
will be addressed as IETF Last Call comments.

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

Date: Mon, 11 Feb 2008 16:00:41 -0600
From: Tony Hansen <[email-masked]>
To: [email-masked]
Subject: Re: 2822upd-06 submitted
Sender: [email-masked]

Thank you Arnt. I think that provides a good summary for this topic and 
jives with my take on the pros and cons of changing the spec in this area.

And on that note, and after consultation with Pete, we're going to move 
forward with the current version of the doc into IETF last call.

	Tony Hansen
	[email-masked]

Arnt Gulbrandsen wrote:
> 
> My position (at the end of a longish offline thread) is that
> 
> 1. Sending anything other than colon-space is stupid. I know - I used an 
> MTA that did it for years. People write careless perl scripts to process 
> mail and colon-tab or just-colon gives those scripts indigestion.
> 
> 2. Some people do it (even after careful thought) and 2822-upd is not 
> the kind of document that should render thoughtful, compliant 
> implementations non-compliant.
> 
> I'd like to see a new document that says "here's what you shouldn't do, 
> even though 822 and its successors have allowed it for decades, and even 
> though some people like to do it". (colon-space, multi-address from, 
> etc.) But such a document has to start at PS. 2822-upd isn't that document.
> 
> Arnt
> 

Date: Mon, 11 Feb 2008 20:14:50 +0100
From: Arnt Gulbrandsen <[email-masked]>
To: [email-masked]
Subject: Re: Re: 2822upd-06 submitted
Sender: [email-masked]

My position (at the end of a longish offline thread) is that

1. Sending anything other than colon-space is stupid. I know - I used an 
MTA that did it for years. People write careless perl scripts to 
process mail and colon-tab or just-colon gives those scripts 
indigestion.

2. Some people do it (even after careful thought) and 2822-upd is not 
the kind of document that should render thoughtful, compliant 
implementations non-compliant.

I'd like to see a new document that says "here's what you shouldn't do, 
even though 822 and its successors have allowed it for decades, and 
even though some people like to do it". (colon-space, multi-address 
from, etc.) But such a document has to start at PS. 2822-upd isn't that 
document.

Arnt

Date: Mon, 11 Feb 2008 10:51:02 -0800
To: "Charles Lindsey" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: 2822upd-06 submitted
Cc: [email-masked]
Sender: [email-masked]

On 2/11/08 at 4:49 PM +0000, Charles Lindsey wrote:

>So I think the only renmaining differences between msg-id here and 
>in USEFOR (assuming USEFOR can now get rid of its own attempts to 
>fix the problems) is that 2822bis still allows '>' in a 
>no-fold-literal and USEFOR does not. But we can probably live with 
>that.

I would be made very happy if you can live with that.

>A couple of niggles:
>
>In 2.2.3:
>
>"An unfolded header field has no length restriction and therefore 
>may be infinitely long."
>
>I doubt that is possible :-( . I suggest s/infinitely/indefinately/.

I'll fix that.

>And in Appendix B:
>
>"9.   Removed quoted-pair from domain literals.*"
>
>I think they are removed from no-fold-literals also.

Right.

>And where did that '*' come from?

"Items marked with an asterisk (*) below are items which appear in 
section 4 of this document and therefore can no longer be generated."

>The only remaining issue that I have is the SP after colon business. 
>You asked for some text, someone provided it, Frank approved and I 
>suggested some small improvements. Is there any reason not to 
>proceed with that?

I had a couple of offline comments on the form of the text and 
alternative formulations. I will encourage those folks to share their 
comments on the list.

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:5289
Path: clerew!chl
From: "Charles Lindsey" <[email-masked]>
Subject: Re: 2822upd-06 submitted
Date: Mon, 11 Feb 2008 16:49:11 GMT
Lines: 43
Sender: [email-masked]

In <p06250120c3ca8525e3ea@[74.134.5.163]> Pete Resnick <[email-masked]> writes:

>I couldn't get the upload tool working, so I mailed it in. You can 
>see it at my website as usual:

OK, I have compared it with -04, and it is mostly fine. In particular the
<quoted-pair> is now gone from the places where it could have caused any
trouble. So I think the only renmaining differences between msg-id here
and in USEFOR (assuming USEFOR can now get rid of its own attempts to fix
the problems) is that 2822bis still allows '>' in a no-fold-literal and
USEFOR does not. But we can probably live with that. Perhaps Frank could
confirm that there are no other msg-id interoperability issues left.

A couple of niggles:

In 2.2.3:

"An unfolded header field has no length restriction and therefore may be
infinitely long."

I doubt that is possible :-( . I suggest s/infinitely/indefinately/.

And in Appendix B:

"9.   Removed quoted-pair from domain literals.*"

I think they are removed from no-fold-literals also. And where did that
'*' come from?

The only remaining issue that I have is the SP after colon business. You
asked for some text, someone provided it, Frank approved and I suggested
some small improvements. Is there any reason not to proceed with that?

-- 
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]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: 2822upd-06 submitted
Date:  Tue, 5 Feb 2008 19:09:12 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 96
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Pete Resnick wrote:

[quotes rearranged]

>>---- Last Call now ?
 
> Tony? I'm all for it.

Catch that runaway 2821bis, and maybe even Usefor.

Both are not directly affected by the fine prine
print of <obs-NO-WS-CTL> in <obs-dtext>.  They
have their own ways of saying "no obs" or "no CTL".

 [routes] 
> Which flatly disagreed with 822 on this point:

Yes, and my point was that this was always wrong
in the RFC 822 syntax.  If you think that serial
commas work as expected in a route it is fine, but
"something" has to trim them for SMTP.

And we are talking about "something" that ignores
several SHOULD NOT in 2821bis and 2822upd.  I have
no idea what happens if serial commas end up in
SMTP paths, stricty speaking this is a syntax error.

> it was always the case that things which generated
> 821 commands from 822 headers had to do all sorts
> of normalization. This one is no different.

Maybe.  But it is "within" the address (or actually
the path), likely within angle brackets.  Forgetting
to trim serial commas is a plausible bug, the place
where this might be rejected as SMTP syntax error
can be far away.

Normally I prefer to avoid such foreseeable trouble.
Of course agents trying to use routes are already
in so much trouble that nits are likely irrelevant :-)

> text before the ABNF is always about syntax and the
> text after the ABNF is always about semantics. See 3.1.

ACK - I missed that editorial rule in 3.1 on page 10,
its effect in 4.4 on page 33 is merely consistent.

 [obs-empty-list] 
> its only reason for existing is the obsolete form of
> group lists.

General, I love it if I can "see" an underlying concept
directly in the ABNF.  I consider "ABNF-beautification"
as essential.  RFC 822 never wanted to introduce ASCII
art by serial commas, it is just a silly side effect of
its #-rule.  

2822upd reintroduces inadvertently lost parts of this
#-rule.  The first attempt <obs-commas> highlighted the
aspect "this is some obsolete silliness with commas".

But this didn't reflect the spirit of RFC 822, where the
commas were only a side effect of its (liberal) #-rule.

Therefore you fixed the syntax for obsolete non-empty
lists, getting rid of <obs-commas> for non-empty lists.

In a certain sense you still have <obs-commas> hidden in
three cases of empty lists:  <obs-group-list>, and in a
part of the ABNF in <obs-bcc> plus <obs-resent-bcc>.

There is no "group" in <obs-group-list>, in fact this is
no "group list".  It's only a consequence of deprecating
serial commas, where you have to cover the pathological
case of an empty list.

And with <obs-empty-list> you could say it as it is:

| group-list = mailbox-list / CFWS / obs-empty-list
[...]
| obs-bcc = "Bcc" *WSP ":"
|           address-list / CFWS / obs-empty-list CRLF
[...]
| obs-empty-list = 1*([CFWS] ",") [CFWS] 

Ditto for <obs-resent-bcc>, and IMO it better expresses
the point of what's going on in these three cases than:

| obs-bcc = "Bcc" *WSP ":"
|           address-list / (*([CFWS] ",") [CFWS]) CRLF

> (*Shrug*) I just can't get excited about this one.

Getting excited about ABNF-beautification is my spleen.

 Frank

Date: Mon, 04 Feb 2008 12:14:45 -0800
From: Dave Crocker <[email-masked]>
Reply-To: [email-masked]
Organization: Brandenburg InternetWorking
To: [email-masked], ietf-822 <[email-masked]>, Apps Discuss <[email-masked]>
Subject: [Fwd: STD 68, RFC 5234 on Augmented BNF for Syntax Specifications: ABNF]
Sender: [email-masked]

FYI.

(Sorry for the cross-posting, but I can't think of a single-best list to post to.)

-------- Original Message --------
Subject: STD 68, RFC 5234 on Augmented BNF for Syntax Specifications: ABNF
Date: Thu, 31 Jan 2008 17:24:14 -0800 (PST)
From: [email-masked]
To: [email-masked], [email-masked]
CC: [email-masked]

A new Request for Comments is now available in online RFC libraries.

         STD 68
         RFC 5234

         Title:      Augmented BNF for Syntax Specifications:
                     ABNF
         Author:     D. Crocker, Ed.,
                     P. Overell
         Status:     Standards Track
         Date:       January 2008
         Mailbox:    [email-masked],
                     [email-masked]
         Pages:      16
         Characters: 26359
         Obsoletes:  RFC4234
         See Also:   STD0068

         I-D Tag:    draft-crocker-rfc4234bis-01.txt

         URL:        http://www.rfc-editor.org/rfc/rfc5234.txt

Internet technical specifications often need to define a formal
syntax.  Over the years, a modified version of Backus-Naur Form
(BNF), called Augmented BNF (ABNF), has been popular among many
Internet specifications.  The current specification documents ABNF.
It balances compactness and simplicity with reasonable
representational power.  The differences between standard BNF and
ABNF involve naming rules, repetition, alternatives,
order-independence, and value ranges.  This specification also
supplies additional rule definitions and encoding for a core lexical
analyzer of the type common to several Internet specifications.
[STANDARDS TRACK]

This is now a Standard Protocol.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

Date: Mon, 4 Feb 2008 13:17:28 -0600
To: "Frank Ellermann" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: 2822upd-06 submitted
Cc: [email-masked]
Sender: [email-masked]

On 2/4/08 at 7:38 AM +0100, Frank Ellermann wrote:

>RFC 821 uses the syntax:
>
>| <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
>| <at-domain> ::= "@" <domain>

Which flatly disagreed with 822 on this point:

      route       =  1#("@" domain) ":"           ; path-relative

      2.7.  #RULE:  LISTS

           A construct "#" is defined, similar to "*", as follows:

                               <l>#<m>element

      indicating at least <l> and at most <m> elements, each  separated
      by  one  or more commas (","). This makes the usual form of lists
      very easy; a rule such as '(element *("," element))' can be shown
      as  "1#element".   Wherever this construct is used, null elements
      are allowed, but do not  contribute  to  the  count  of  elements
      present.   That  is,  "(element),,(element)"  is  permitted,  but
      counts as only two elements.  Therefore, where at least one  ele-
      ment  is required, at least one non-null element must be present.
      Default values are 0 and infinity so that "#(element)" allows any
      number,  including  zero;  "1#element" requires at least one; and
      "1#2element" allows one or two.

And remember, it was always the case that things which generated 821 
commands from 822 headers had to do all sorts of normalization. This 
one is no different.

>Why do 2822 and 2822upd keep the...

Only in the obs- syntax because you still need to parse these things.

>---- 2: Routes SHOULD be ignored
>
>>When interpreting addresses, the route portion SHOULD be ignored.
>
>That statement in isolation *after* the syntax is odd, why not add 
>it to the prose before the ABNF?

Because the text before the ABNF is always about syntax and the text 
after the ABNF is always about semantics. See 3.1.

>---- 3: <obs-group-list>
>
>That's a kind of <obs-mbox-list> without <mailbox>, but at least one 
>comma.  Anything else is covered elsewhere. Rather obscure, how 
>about renaming it, <obs-empty-list> ?

Because its only reason for existing is the obsolete form of group lists.

>You could use <obs-empty-list> three times, where you have it as 
><obs-group-list>, and to simplify <obs-bcc>

(*Shrug*) I just can't get excited about this one. I think it's clear 
enough. If there are others who think a de-reference would be better, 
I'll go back and take a look.

>Why do 2822 and 2822upd keep the RFC 822 <obs-NO-WS-CTL> in 
><obs-dtext>, when it was never allowed in (2)821(bis) ?

I'm staying out of this one. Convince enough others, I will change 
it. Don't, I won't.

>- period character is currently used in many messages in
>- the display-name portion of addresses
>+ period character is sometimes erroneously used in
>+ messages in the display-name portion of addresses

Again, I can't get excited about this. We're already in the obs- 
syntax, where it's perfectly clear that none of these things are 
correct to generate. Seems redundant. Unless others think it's 
unclear, I'll leave it.

>---- Last Call now ?

Tony? I'm all for it.

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: 2822upd-06 submitted
Date:  Mon, 4 Feb 2008 07:38:43 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 96
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Pete Resnick wrote:
 
> And the diff from -05

Thanks.  Stuff I stumbled over while looking at the diff:

---- 1: <obs-domain-list>

RFC 821 uses the syntax:

| <a-d-l> ::= <at-domain> | <at-domain> "," <a-d-l>
| <at-domain> ::= "@" <domain>

RFC 2821 and 2821bis agree with that idea:  There are no
"null" <at-domain>s.  Why do 2822 and 2822upd keep the
RFC 822 ASCII-art commas in source routes, when that was
never allowed in (2)821(bis) ?

---- 2: Routes SHOULD be ignored

| When interpreting addresses, the route portion SHOULD
| be ignored. 

That statement in isolation *after* the syntax is odd,
why not add it to the prose before the ABNF ?  Proposal:

= There are four primary differences in addressing.  First,
= mailbox addresses were allowed to have a route portion
= before the addr-spec when enclosed in "<" and ">".  The
= route is simply a comma-separated list of domain names,
= each preceded by "@", and the list terminated by a colon.
+ When interpreting addresses, the route portion SHOULD be
+ ignored.
+
= Second, CFWS were allowed between the period-separated
= [...rest as is...]

At the moment 2821bis still says "SHOULD be ignored", with
"MUST be stripped down" only for error notifications.  It
would be nice if 2821bis and 2822upd say "MUST be ignored",
but of course that's mainly a problem in 2821 and 2821bis. 

---- 3: <obs-group-list>

That's a kind of <obs-mbox-list> without <mailbox>, but
at least one comma.  Anything else is covered elsewhere.
Rather obscure, how about renaming it, <obs-empty-list> ?

You could use <obs-empty-list> three times, where you
have it as <obs-group-list>, and to simplify <obs-bcc>:

= obs-bcc = "Bcc" *WSP ":"
-           address-list / (*([CFWS] ",") [CFWS]) CRLF
+           address-list / CFWS / obs-empty-list CRLF

Ditto in <obs-resent-bcc>.  The case "only CFWS, no comma"
needs an explicit CFWS, the same idea as in <group-list>:

| group-list = mailbox-list / CFWS / obs-group-list

---- 4: obs-dtext

RFC 821 uses the syntax (for domain literals):

| <element> ::= <name> | "#" <number> | "[" <dotnum> "]"
| <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>

In essence RFC 2821 and 2821bis agree with that idea, no
control characters in domain literals.  Why do 2822 and
2822upd keep the RFC 822 <obs-NO-WS-CTL> in <obs-dtext>,
when it was never allowed in (2)821(bis) ?  Did the DRUMS
Charter a decade ago force 2822 to keep RFC 822 errors ?

IMO you can limit <obs-dtext> to <quoted-pair>.  Nobody
produced cases where "MUST accept obs-NO-WS-CTL in domain
literals" is REQUIRED (as specified in RFC 2119 1 and 6).

---- 5: obs-phrase

- period character is currently used in many messages in
- the display-name portion of addresses
+ period character is sometimes erroneously used in 
+ messages in the display-name portion of addresses

Most users have no problem to use a <quoted-string> where
it is required, <atom> simply cannot permit trailing dots.

---- Last Call now ?

 Frank

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  Re: 2822upd-06 Sender
Date:  Mon, 4 Feb 2008 06:24:26 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 51
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Pete Resnick wrote:
 
> There are cases where it is REQUIRED (section 1 of 2119) and
> cases where "there may exist valid reasons in particular 
> circumstances to" not have a Sender, "but the full implications
> must be understood and carefully weighed before choosing 
> a different course" (section 3 of 2119).

Right, and that can be difficult if the sender has no idea
about auth* schemes building on accurate info (SenderID and
maybe some future DKIM SSP scenarios).

> - The agent responsible for the actual transmission of the
>   message is the company lawyer who vets every e-mail
>   message before sending it out. But the lawyer's identity
>   should not be revealed to the rest of the world for
>   security reasons.

They could use a role account for this task.  Or pretend that
the author submitted the mail when the real Sender would be
in the same domain (i.e. most likely irrelevant).

> - The agent responsible for transmission is *really* hard to 
>   determine. A particular system may have an audit log which
>   can figure out who sent it later, but that information is
>   unavailable when the message itself is being sent.

RFC 4409 8.1 is clearly an OPTION, and as long as it is about
the same domain I don't care about SHOULD vs. MUST.  But for
a Sender in another domain I'm not sure about this conclusion:

> It certainly lowers interoperability to not have a Sender
> when there  is a single author and we know the transmitter is
> different from the author, but only insofar as we have lost
> information. But it does not eliminate interoperability.

FWIW, the technical part of the SPF vs. SenderID controversy
boiled down to "4409 8.1 is no MUST, besides envelope sender
and Sender can be in different domains even if the Sender is
correct".

And for DKIM-SSP they now apparently arrived at the conclusion
that SSS is actually ASP (= s/Sender/Author/ in the acronym).

The lost information can be critical for schemes assuming that
it is present.  2822upd could note something in the direction
of your examples, showing that such assumptions are erroneous
to start with.  I'm not hot about it, but it is good to know
that the SHOULD in 2822upd 3.6.2 is *intentionally* no MUST. 

 Frank

Date: Sun, 3 Feb 2008 21:39:48 -0600
To: "Frank Ellermann" <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: Re: 2822upd-06 Sender
Cc: [email-masked], "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

On 2/4/08 at 3:08 AM +0100, Frank Ellermann wrote:

>Hi, on the DKIM list a poster claimed that Sender is OPTIONAL.

Of course, that's obviously false. Sender is not OPTIONAL (defined in 
section 5 of RFC 2119). There are cases where it is REQUIRED (section 
1 of 2119) and cases where "there may exist valid reasons in 
particular circumstances to" not have a Sender, "but the full 
implications must be understood and carefully weighed before choosing 
a different course" (section 3 of 2119). As you say:

>1:  from multiple authors    => MUST (table 3.6 and in 3.6.2)
>2:  one author = transmitter => SHOULD NOT (redundant, 3.6.2)
>3:  otherwise SHOULD (3.6.2)
>
>I don't get case (3), why is it only a SHOULD ?  For anything that's 
>not covered by (2: one author = transmitter) I'd expect a MUST:
>
>- Otherwise, both fields SHOULD appear.
>+ Otherwise, both fields MUST appear.
>
>What could be a plausible excuse to ignore the SHOULD in (3) ?

Two that I can come up with off the top of my head:

- The agent responsible for the actual transmission of the message is 
the company lawyer who vets every e-mail message before sending it 
out. But the lawyer's identity should not be revealed to the rest of 
the world for security reasons.

- The agent responsible for transmission is *really* hard to 
determine. A particular system may have an audit log which can figure 
out who sent it later, but that information is unavailable when the 
message itself is being sent.

It certainly lowers interoperability to not have a Sender when there 
is a single author and we know the transmitter is different from the 
author, but only insofar as we have lost information. But it does not 
eliminate interoperability. Not having a Sender when there are two 
authors *definitely* can damage interoperability since you simply 
*can't* determine any value for the Sender.

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

Date: Sun, 03 Feb 2008 22:10:04 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc
To: Frank Ellermann <[email-masked]>
CC: [email-masked]
Subject: Re: 2822upd-06 Sender
Sender: [email-masked]

Frank Ellermann wrote:
> Hi, on the DKIM list a poster claimed that Sender is OPTIONAL.
> Looking for the evidence why that's wrong in 2822upd I found
> an unclear SHOULD:
> 
> 1:  from multiple authors    => MUST (table 3.6 and in 3.6.2)
> 2:  one author = transmitter => SHOULD NOT (redundant, 3.6.2)
> 3:  otherwise SHOULD (3.6.2)
> 
> I don't get case (3), why is it only a SHOULD ?  For anything
> that's not covered by (2: one author = transmitter) I'd expect
> a MUST:
> 
> - Otherwise, both fields SHOULD appear.
> + Otherwise, both fields MUST appear.
> 
> What could be a plausible excuse to ignore the SHOULD in (3) ?

Nothing wrong with the statement in 2822 section 3.6.2:

    If the originator of the message can be indicated
    by a single mailbox and the author and transmitter are identical, the
    "Sender:" field SHOULD NOT be used.  Otherwise, both fields SHOULD
    appear.

-1 only trying to change something that isn't broken and on enforcing 
something that will immediately make existing systems non-compliant for 
no reality plausible reason.

-- 
HLS

To: [email-masked]
From: "Frank Ellermann" <[email-masked]>
Subject:  2822upd-06 Sender
Date:  Mon, 4 Feb 2008 03:08:10 +0100
Organization:  <http://purl.net/xyzzy>
Lines: 18
Reply-To: "Frank Ellermann" <[email-masked]>
Sender: [email-masked]

Hi, on the DKIM list a poster claimed that Sender is OPTIONAL.
Looking for the evidence why that's wrong in 2822upd I found
an unclear SHOULD:

1:  from multiple authors    => MUST (table 3.6 and in 3.6.2)
2:  one author = transmitter => SHOULD NOT (redundant, 3.6.2)
3:  otherwise SHOULD (3.6.2)

I don't get case (3), why is it only a SHOULD ?  For anything
that's not covered by (2: one author = transmitter) I'd expect
a MUST:

- Otherwise, both fields SHOULD appear.
+ Otherwise, both fields MUST appear.

What could be a plausible excuse to ignore the SHOULD in (3) ?

 Frank

Date: Sat, 2 Feb 2008 14:41:35 -0600
To: ietf-822 <[email-masked]>
From: Pete Resnick <[email-masked]>
Subject: 2822upd-06 submitted
Sender: [email-masked]

I couldn't get the upload tool working, so I mailed it in. You can 
see it at my website as usual:

<http://resnick1.qualcomm.com/draft-resnick-2822upd-06.txt>
<http://resnick1.qualcomm.com/draft-resnick-2822upd-06.html>
<http://resnick1.qualcomm.com/draft-resnick-2822upd-06.xml>

And the diff from -05 here:

http://tools.ietf.org/rfcdiff?url1=http://resnick1.qualcomm.com/draft-resnick-2822upd-05.txt&url2=http://resnick1.qualcomm.com/draft-resnick-2822upd-06.txt

Basically, re-fixed all of the -list constructs (no more obs-commas) 
and made a couple of editorial fixes.

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