Subject: Re: Received,mailbox-list,address-list parsing.
From: mouss <[email-masked]>
To: Ivar Lumi <[email-masked]>
Cc: John C Klensin <[email-masked]>, [email-masked]
Date: Sat, 20 Dec 2008 23:21:33 +0100
List-Id: <ietf-smtp.imc.org>

Ivar Lumi a écrit :
> 
> 
>> But please do not confuse the mailbox syntax of SMTP (5321,
>> etc.) with that of the message body and headers (5322, etc.).
> Hmm no i see, there is problematic place. Bot declare "mailbox" term.
> Also both RFC cross refer each other:
> RFC 5322 3.6.7 has some definition for received and refers to RFC 5321.
> 
> RFC 5321 4.4   The time stamp line and the return path line are formally
> defined as
>   follows (the definitions for "FWS" and "CFWS" appear in RFC 5322
> <./rfc5322> [4 <#ref-4>]):
> 
> 
>> Please reread the text that discourages machine interpretation
>> of trace fields.
> After fast re look, i can't find it, can you point section where it is.
> About address-list, yes probably this is probably wrong list to ask how
> there addresses distinguished.
> 

RFC 5321, section 3.7.2:

  "Received:" header fields of messages originating from other
   environments may not conform exactly to this specification. ...

Date: Thu, 18 Dec 2008 13:34:24 +0000
From: Tony Finch <[email-masked]>
To: Ivar Lumi <[email-masked]>
cc: [email-masked]
Subject: Re: Received,mailbox-list,address-list parsing.
Sender: [email-masked]

On Thu, 18 Dec 2008, Ivar Lumi wrote:
>
>    ///     For            = CFWS "FOR" FWS ( Path / Mailbox )
>
> Here for can be path / or mailbox, detecting if value is apth or angle-addr
> isn't problem. But if value is mailbox.
>
>    ///     mailbox    = name-addr / addr-spec
>    ///     name-addr  = [display-name] angle-addr
>    ///     angle-addr = [CFWS] "&lt;" addr-spec "&gt;" [CFWS]

No, Path / Mailbox is different from path / mailbox. The title case
versions are defined in RFC 5321 and the lower case versions in RFC 5322.
You are looking at the wrong one.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTH FITZROY: NORTHERLY 3 OR 4, OCCASIONALLY 5 IN SOUTHEAST. ROUGH OR VERY
ROUGH. MAINLY FAIR. MODERATE OR GOOD.

Date: Thu, 18 Dec 2008 15:04:46 +0200
From: Ivar Lumi <[email-masked]>
To: John C Klensin <[email-masked]>
CC: [email-masked]
Subject: Re: Received,mailbox-list,address-list parsing.
Sender: [email-masked]

>But please do not confuse the mailbox syntax of SMTP (5321,
>etc.) with that of the message body and headers (5322, etc.).
Hmm no i see, there is problematic place. Bot declare "mailbox" term.
Also both RFC cross refer each other:
RFC 5322 3.6.7 has some definition for received and refers to RFC 5321.

RFC 5321 4.4 
   The time stamp line and the return path line are formally defined as
   follows (the definitions for "FWS" and "CFWS" appear in RFC 5322 <./rfc5322> [4 <#ref-4>]):

>Please reread the text that discourages machine interpretation
>of trace fields.
After fast re look, i can't find it, can you point section where it is. 

About address-list, yes probably this is probably wrong list to ask how there addresses distinguished.

Thanks

John C Klensin wrote:
>
> --On Thursday, 18 December, 2008 13:48 +0200 Ivar Lumi
> <[email-masked]> wrote:
>
>   
>> Here for can be path / or mailbox, detecting if value is apth
>> or angle-addr isn't problem. But if
>> value is mailbox.
>>
>> ///         mailbox    = name-addr / addr-spec
>>     ///     name-addr  = [display-name] angle-addr
>>     ///     angle-addr = [CFWS] "&lt;" addr-spec "&gt;" [CFWS]
>>
>> mailbox syntax allows: 3 value combinations.
>> 1) [email-masked]
>> 2) <[email-masked]>
>> 3) john <[email-masked]>
>> --
>> Is that allowed(without quotes): 4) john doe
>> <[email-masked]>
>>     
>
> Where display names are permitted at all, both (3) and (4) are
> allowed without quotes.  The quotes are needed only if special
> characters appear in the string.
>
> But please do not confuse the mailbox syntax of SMTP (5321,
> etc.) with that of the message body and headers (5322, etc.).
> The former doesn't recognize that name phrase at all.
>
>
>   
>> If i get right, the only way to parse received value is block
>> by block from left to right.
>>     
>
> Please reread the text that discourages machine interpretation
> of trace fields.  But, yes, you do need to proceed from left to
> right with considerable look-ahead.
>
>   
>> So how to distinguish what address type it is ? Is the only
>> way to read ahead and then to guess whats it is ?
>>     
>
> I wouldn't say "guess", because it is deterministic.
>
>   
>> Similar case is with address-list, it may contain mailbox or
>> group addresses, so who to distinguish address here ?
>>
>>     ///     address-list = (address *("," address))
>>     ///     address      = mailbox / group
>>
>> String split can't be used to split addresses and then process
>> each as block, so addresses must be read continuously. Or i
>> miss some thing.
>>     
>
> You are confusing the envelope and the headers.  SMTP has never
> heard of an address list and, consequently, neither have the
> trace header fields.   I hope that, in moving definitions
> between 2822 and 2821, we didn't foul this up.  If we did, it is
> a bug.
>
>   
>> I'm trying to find bullet-proof way to parse this values.
>>     
>
> Why?  (Again, see the text that prohibits trying to interpret
> these fields for much of anything besides debugging by humans.)
>
>      john
>
>
>
>   

Date: Thu, 18 Dec 2008 07:29:57 -0500
From: John C Klensin <[email-masked]>
To: Ivar Lumi <[email-masked]>, [email-masked]
Subject: Re: Received,mailbox-list,address-list parsing.
Sender: [email-masked]

--On Thursday, 18 December, 2008 13:48 +0200 Ivar Lumi
<[email-masked]> wrote:

> Here for can be path / or mailbox, detecting if value is apth
> or angle-addr isn't problem. But if
> value is mailbox.
> 
> ///         mailbox    = name-addr / addr-spec
>     ///     name-addr  = [display-name] angle-addr
>     ///     angle-addr = [CFWS] "&lt;" addr-spec "&gt;" [CFWS]
> 
> mailbox syntax allows: 3 value combinations.
> 1) [email-masked]
> 2) <[email-masked]>
> 3) john <[email-masked]>
> --
> Is that allowed(without quotes): 4) john doe
> <[email-masked]>

Where display names are permitted at all, both (3) and (4) are
allowed without quotes.  The quotes are needed only if special
characters appear in the string.

But please do not confuse the mailbox syntax of SMTP (5321,
etc.) with that of the message body and headers (5322, etc.).
The former doesn't recognize that name phrase at all.

> If i get right, the only way to parse received value is block
> by block from left to right.

Please reread the text that discourages machine interpretation
of trace fields.  But, yes, you do need to proceed from left to
right with considerable look-ahead.

> So how to distinguish what address type it is ? Is the only
> way to read ahead and then to guess whats it is ?

I wouldn't say "guess", because it is deterministic.

> Similar case is with address-list, it may contain mailbox or
> group addresses, so who to distinguish address here ?
> 
>     ///     address-list = (address *("," address))
>     ///     address      = mailbox / group
> 
> String split can't be used to split addresses and then process
> each as block, so addresses must be read continuously. Or i
> miss some thing.

You are confusing the envelope and the headers.  SMTP has never
heard of an address list and, consequently, neither have the
trace header fields.   I hope that, in moving definitions
between 2822 and 2821, we didn't foul this up.  If we did, it is
a bug.

> I'm trying to find bullet-proof way to parse this values.

Why?  (Again, see the text that prohibits trying to interpret
these fields for much of anything besides debugging by humans.)

     john

Date: Thu, 18 Dec 2008 13:48:21 +0200
From: Ivar Lumi <[email-masked]>
To: [email-masked]
Subject: Received,mailbox-list,address-list parsing.
Sender: [email-masked]

Hi,

After bigger reading and coding, some questions arise.

Like:

 /// RFC 5321 4.4.
    ///     Time-stamp-line = "Received:" FWS Stamp CRLF
    ///    
    ///     Stamp           = From-domain By-domain Opt-info [CFWS] ";" 
FWS date-time
    ///                     ; where "date-time" is as defined in RFC 
5322 [4]
    ///                     ; but the "obs-" forms, especially two-digit
    ///                     ; years, are prohibited in SMTP and MUST NOT 
be used.
    ///                    
    ///     From-domain     = "FROM" FWS Extended-Domain
    ///
    ///     By-domain       = CFWS "BY" FWS Extended-Domain
    ///
    ///     Extended-Domain = Domain / ( Domain FWS "(" TCP-info ")" ) / 
( address-literal FWS "(" TCP-info ")" )
    ///
    ///     TCP-info        = address-literal / ( Domain FWS 
address-literal )
    ///                     ; Information derived by server from TCP 
connection not client EHLO.
    ///
    ///     Opt-info        = [Via] [With] [ID] [For] 
[Additional-Registered-Clauses]
    ///
    ///     Via             = CFWS "VIA" FWS Link
    ///
    ///     With            = CFWS "WITH" FWS Protocol
    ///
    ///     ID              = CFWS "ID" FWS ( Atom / msg-id )
    ///                     ; msg-id is defined in RFC 5322 [4]
    ///
    ///     For            = CFWS "FOR" FWS ( Path / Mailbox )

Here for can be path / or mailbox, detecting if value is apth or 
angle-addr isn't problem. But if
value is mailbox.

///         mailbox    = name-addr / addr-spec
    ///     name-addr  = [display-name] angle-addr
    ///     angle-addr = [CFWS] "&lt;" addr-spec "&gt;" [CFWS]

mailbox syntax allows: 3 value combinations.
1) [email-masked]
2) <[email-masked]>
3) john <[email-masked]>
--
Is that allowed(without quotes): 4) john doe <[email-masked]>

If i get right, the only way to parse received value is block by block 
from left to right.
So how to distinguish what address type it is ? Is the only way to read 
ahead and then to guess whats it is ?

Similar case is with address-list, it may contain mailbox or group 
addresses, so who to distinguish address here ?

    ///     address-list = (address *("," address))
    ///     address      = mailbox / group

String split can't be used to split addresses and then process each as 
block, so addresses must be read continuously. Or i miss some thing.

I'm trying to find bullet-proof way to parse this values.

Any comments are welcome.

Thanks,

Date: Tue, 16 Dec 2008 07:22:30 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: John C Klensin <[email-masked]>
CC:  [email-masked]
Subject: Re: RFC5321bis / RFC 2821ter
Sender: [email-masked]

Hector Santos wrote:
> John,
> 
> I'm not privy to all the details of this issue, but I am not quite 
> understanding something:
> 
> Doesn't our document should fall under some common sense and "natural 

Sorry, I need a new keyboard. That should be YOUR document. :-)

-- 
Sincerely

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

Date: Tue, 16 Dec 2008 07:20:53 -0500
From: Hector Santos <[email-masked]>
Organization: Santronics Software, Inc.
To: John C Klensin <[email-masked]>
CC:  [email-masked]
Subject: Re: RFC5321bis / RFC 2821ter
Sender: [email-masked]

John,

I'm not privy to all the details of this issue, but I am not quite 
understanding something:

Doesn't our document should fall under some common sense and "natural 
law" grandfather clause since its a) it is an update (as opposed to 
new), b) was initiated prior to RFC 5278 official publication by 
nearly 25 years?

Based on what I read in provision 2.d of:

    http://trustee.ietf.org/docs/IETF-Trust-License-Policy.pdf

    2.d. In most cases, rights to Pre-Existing IETF Documents that
    are not expressly granted under these RFCs can only be obtained
    by requesting such rights directly from the document authors. The
    IETF Trust and the Internet Society do not become involved in
    making such requests to document authors.

So it sounds to me, the trust is not making claims to prior art 
(Pre-existing IETF Document prior to the effective date November 10, 
2008) and it did, it could only do so by contacting the authors of 
prior art. This is something they do no wish to get involved with in 
"making such request of document authors."

In addition, in regards to prior art, in section 3.a.ii. it states a 
License For Use Within the IETF Standards Process where:

         iii: unless explicitly disallowed in the notices contained in
    an IETF Contribution or IETF Document (as specified in Section 6.b
    below), to modify or prepare derivative works of such IETF
    Contributions or IETF Documents, in whole or in part, as part of
    the IETF Standards Process.

So as long as the derivative work remains within IETF and not taken by 
some company for non-standard proprietary usage, its all good.

I think RFC 5321 fulls under prior art for IETF standards process.

-- 
Sincerely

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

John C Klensin wrote:
> Hi.
> 
> After a lengthy discussion with my attorney about the RFC5321bis
> draft which I had hoped to post within the next week or ten
> days, I've reached two conclusions.  These conclusions obvious
> do not constitute legal advice, from me or anyone else, to
> anyone on the list.  They are simply explanations to this group
> about actions I'm taking.  The first of them is inconsistent
> with assertions made by the IETF Chair on the IETF list and
> elsewhere; I do not have an opinion as to whether his remarks
> constitute legal advice or not.
> 
> 	(1) As long as I am permitted to do so by the posting
> 	tools and the Secretariat, and at least until the Note
> 	Well statements are updated, it is reasonably safe to
> 	post documents that refer only to RFC 3978 and the
> 	associated boilerplate, if those postings are done for
> 	IETF Standards purposes, without obtaining an explicit
> 	release of RFC 5378 rights to the IETF Trust from all
> 	contributors of text in the document.
> 	
> 	(2) Posting a draft that uses text from others and that
> 	references or incorporates RFC 5378 copyright transfer
> 	requirement is prohibited unless formal releases of
> 	rights from all contributors of text are on file with
> 	the IETF Trust.  Ignoring that prohibition or trying to
> 	slide around it is not acceptable, at least to me under
> 	the advice I've been given.
> 
> As I presume everyone reading this is aware, RFC 2821 carried
> forward a considerable amount of Jon Postel's text from RFC 821.
> Most of that text, including some of the formerly-contentious
> examples, is still present in 5321 and would have been present
> in 5321bis.  While I believe that Jon would have granted the
> rights to the IETF Trust that RFC 5378 requires, I have no
> plausible way to verify that belief, much less any way to get
> the required releases and transfers filed with the IETF Trust.
> I have been advised that, if I, as Contributor of the current
> versions, have to take personal responsibility for the validity
> of such releases as 5378 appears to require, I should not
> recognize any such release from Jon's estate unless it is
> formally endorsed by a cognizant court _and_ USC/ISI formally
> release any rights they might have to his individual work for
> the IETF and its predecessors.
> 
> I am, and remain, optimistic that the IETF will figure out a way
> out of what appears to me to be a self-created impasse.
> 
> In order to facilitate making progress in the interim, I've just
> queued an I-D, draft-klensin-rfc5321-numbered-00.txt, for
> posting (with RFC 3978 boilerplate) that is essentially a
> facsimile of RFC5321 with line numbers inserted to permit
> precise references to specific text.    There will no -01 of
> that document, nor will there be any attempt to have it posted.
> I would not have taken that action at this time except that I
> expect the window on postings with RFC 3978 boilerplate to close
> within the next 48 hours.
> 
> Until it is possible to post draft-klensin-rfc5321bis itself,
> suggested changes will be posted only as diffs with reference to
> those line numbers and without incorporating any text whose
> ownership I cannot guarantee to my satisfaction and that of the
> IETF Trust.  I hope that these issues can be resolved soon
> enough that we do not have to ask the IESG to act on the Diffs,
> but note that there does not appear to be anything in RFC 2026
> that would prohibit having a base document plus corrections as
> an Internet Standard.
> 
> Sadly,
>     john
> 
> 
> 

Date: Sun, 14 Dec 2008 20:56:20 -0800 (PST)
From: [email-masked]
Subject: Re: RFC5321bis / RFC 2821ter
To: John C Klensin <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

> ...

> As I presume everyone reading this is aware, RFC 2821 carried
> forward a considerable amount of Jon Postel's text from RFC 821.
> Most of that text, including some of the formerly-contentious
> examples, is still present in 5321 and would have been present
> in 5321bis.  While I believe that Jon would have granted the
> rights to the IETF Trust that RFC 5378 requires, I have no
> plausible way to verify that belief, much less any way to get
> the required releases and transfers filed with the IETF Trust.
> I have been advised that, if I, as Contributor of the current
> versions, have to take personal responsibility for the validity
> of such releases as 5378 appears to require, I should not
> recognize any such release from Jon's estate unless it is
> formally endorsed by a cognizant court _and_ USC/ISI formally
> release any rights they might have to his individual work for
> the IETF and its predecessors.

> I am, and remain, optimistic that the IETF will figure out a way
> out of what appears to me to be a self-created impasse.

Speaking as another contributor who had Jon Postel as a coauthor,
I must say I'm very worried by this mess. But the thing that worries 
me most is, unless I've missed some message on the IETF list, there
seems to be a rather stunning lack of apprecation of the existance
of this impasse amongst the powers-that-be.

The situation in regards to Jon Postel arguably affects a huge number of
documents because, as I'm sure you recall, at the time documents like RFC
1341/1342 (the original MIME specifications) were published Jon as RFC Editor
intpreted the editorial brief rather broadly and in many cases changed or
otherwise contributed text to many if not most documents that were published.

I also have to say that the thought of having to toddle off to my own lawyer
for advice on this doesn't exactly fill me with glee.

				Ned

Date: Sun, 14 Dec 2008 16:17:13 -0500
From: John C Klensin <[email-masked]>
To: [email-masked]
Subject: RFC5321bis / RFC 2821ter
Sender: [email-masked]

Hi.

After a lengthy discussion with my attorney about the RFC5321bis
draft which I had hoped to post within the next week or ten
days, I've reached two conclusions.  These conclusions obvious
do not constitute legal advice, from me or anyone else, to
anyone on the list.  They are simply explanations to this group
about actions I'm taking.  The first of them is inconsistent
with assertions made by the IETF Chair on the IETF list and
elsewhere; I do not have an opinion as to whether his remarks
constitute legal advice or not.

	(1) As long as I am permitted to do so by the posting
	tools and the Secretariat, and at least until the Note
	Well statements are updated, it is reasonably safe to
	post documents that refer only to RFC 3978 and the
	associated boilerplate, if those postings are done for
	IETF Standards purposes, without obtaining an explicit
	release of RFC 5378 rights to the IETF Trust from all
	contributors of text in the document.
	
	(2) Posting a draft that uses text from others and that
	references or incorporates RFC 5378 copyright transfer
	requirement is prohibited unless formal releases of
	rights from all contributors of text are on file with
	the IETF Trust.  Ignoring that prohibition or trying to
	slide around it is not acceptable, at least to me under
	the advice I've been given.

As I presume everyone reading this is aware, RFC 2821 carried
forward a considerable amount of Jon Postel's text from RFC 821.
Most of that text, including some of the formerly-contentious
examples, is still present in 5321 and would have been present
in 5321bis.  While I believe that Jon would have granted the
rights to the IETF Trust that RFC 5378 requires, I have no
plausible way to verify that belief, much less any way to get
the required releases and transfers filed with the IETF Trust.
I have been advised that, if I, as Contributor of the current
versions, have to take personal responsibility for the validity
of such releases as 5378 appears to require, I should not
recognize any such release from Jon's estate unless it is
formally endorsed by a cognizant court _and_ USC/ISI formally
release any rights they might have to his individual work for
the IETF and its predecessors.

I am, and remain, optimistic that the IETF will figure out a way
out of what appears to me to be a self-created impasse.

In order to facilitate making progress in the interim, I've just
queued an I-D, draft-klensin-rfc5321-numbered-00.txt, for
posting (with RFC 3978 boilerplate) that is essentially a
facsimile of RFC5321 with line numbers inserted to permit
precise references to specific text.    There will no -01 of
that document, nor will there be any attempt to have it posted.
I would not have taken that action at this time except that I
expect the window on postings with RFC 3978 boilerplate to close
within the next 48 hours.

Until it is possible to post draft-klensin-rfc5321bis itself,
suggested changes will be posted only as diffs with reference to
those line numbers and without incorporating any text whose
ownership I cannot guarantee to my satisfaction and that of the
IETF Trust.  I hope that these issues can be resolved soon
enough that we do not have to ask the IESG to act on the Diffs,
but note that there does not appear to be anything in RFC 2026
that would prohibit having a base document plus corrections as
an Internet Standard.

Sadly,
    john