Subject: [EAI] other thought about <eai@address <ascii@address>>

From: Soobok Lee <[email-masked]>
Date: Mon, 29 Jan 2007 19:08:55 +0900

RFC822 allowed 1) below and its successor RFC2822 required angled-address like 0).
But, still we see <>-omitted 1) is popular in headers.

With EAI, we notice that 13) != 11) if we choose <eai@address <ascii@address>>.

0)  To:  <ascii@address>
1)  To:  ascii@address     <-----  <> is omitted 

2)  To:  display_name <ascii@address>  
3 ) To:  "display_name" <ascii@address>  

11) To:  <eai@address <ascii@address>>  
12) To:  <eai@address [ascii@address]>  

13) To:  eai@address <ascii@address>       <----- 
14) To:  eai@address [ascii@address]  
15) To:  eai@address
16) To:  <eai@address>

I guess no MUA implementors would use 13) as abbreviation for 11),
because eai@address is recognized as a display_name part. 

But, if we pill off outer <> from <eai@address <ascii@address>>,
we get eai@address <ascii@address>. 
When comparing 11) and 13), I feel they are visually confusing
and there may be more chance of missing those difference by 
,for example, some careless email programmers.

But, if agree we need not go so far to worry about careless 
programmers's errors like 13), I think <eai@address <ascii@address>> 
is one of good choices.

If we remain with <eai@address [ascii@address]>,
14) has no ambiguity for parsers and for human eyes.  
Parsers can do more than [utf8headers] defines, to parse 14) for flexability.

For me, <eai@address [ascii@address]> is _visually clearer_.
I had not been present in this WG from the beginning, but I guess
authors might have these facts in mind when choosing [].

I  FAVOR  <eai@address [ascii@address]>, 
but, I do not oppose <eai@address <ascii@address>> so hard, 
if you all (but me) like it. :-)

Regards,

Soobok

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: "Charles Lindsey" <[email-masked]>
Date: Mon, 29 Jan 2007 19:40:14 -0000

> 1)  To:  ascii@address     <-----  <> is omitted

Not quite. It is an alternative explicitly allowed by RFC 2822 (but, if  
you use it, you can't have a display-name as well).
> 14) To:  eai@address [ascii@address]

AFAIK, out utf8headers draft does not permit either of those (and if it  
does, it needs to be fixed).

> 16) To:  <eai@address>

And utf8headers permits (I hope) both of those,

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

---

From: Tony Finch <[email-masked]>
Date: Mon, 29 Jan 2007 20:01:42 +0000

On Mon, 29 Jan 2007, Charles Lindsey wrote:
> Not quite. It is an alternative explicitly allowed by RFC 2822 (but, if you
> use it, you can't have a display-name as well).

However you can put a name in a comment.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: SOUTHWESTERLY 6 OR 7, OCCASIONALLY GALE 8. ROUGH OR VERY
ROUGH . RAIN OR DRIZZLE, THEN SHOWERS. MODERATE OR POOR BECOMING GOOD.

---

From: Philip Guenther <[email-masked]>
Date: Mon, 29 Jan 2007 13:37:44 -0700

> However you can put a name in a comment.

Sure, and some MUAs did so.  Others inserted comments containing stuff 
unrelated to the address the comment was next to.  It was common before 
RFC 2822 to see this**:
 	To: original@address (resent to <another@address>)

There's no particular reason to believe that a comment next to an address 
has anything to do with that particular address.  Determining the correct 
semantics of a comment involves heuristics best performed by a human 
being.  To quote the fortune file:
 	Heuristics are bug ridden by definition.  If they didn't have
 	bugs, then they'd be algorithms.

Philip Guenther

** I believe it was an old version of Eudora that did the above, dating 
from when it wasn't clear whether Resent-{To,Cc} would be sent replies. 
Once that was clarified in RFC 2822, it was corrected to generate
 	Resent-To: another@address
 	To: original@address

---

From: Soobok Lee <[email-masked]>
Date: Tue, 30 Jan 2007 09:06:17 +0900

> And utf8headers permits (I hope) both of those,

It is clear that 16) is allowed in [utf8headers] excerpts below.
But, I can't find any link between RFC2822(RFC822) <-> [utf8headers]
that explicitly allows  15) .

As you pointed out, "To: ascii@address" is also allowed explicitly 
in RFC2822.

<quote from rfc2822>
mailbox         =       name-addr / addr-spec   <----

name-addr       =       [display-name] angle-addr

angle-addr      =       [CFWS] "<" addr-spec ">" [CFWS] / obs-angle-addr
</quote>

But, I find this clause is required to allow 15) in [utf8headers].

<quote : i propose to add to [utf8headers] >
mailbox         =       name-addr / addr-spec / utf8-addr-spec  <----
</quote>

The next paragraph from [utf8headers] only defines the angled form 
"<eai@address>".
If "utf8-addr-spec" is defined to supersede (override) "addr-spec"
in sweeping manner, this won't be a problem, but i can't find  such
hints from [utf8headers]. Correct me if I am wrong.

Soobok

<quote from [utf8headers] >
6.3.  Change on addr-spec syntax

   In this specification, internationalized email address will be
   presented in UTF-8.  Thus, all header fields involving <mailbox>es
   may be different from traditional ones.  There might be UTF8SMTP
   unaware MTAs in the mail routing path.  In that case, MTA may bounce
   the message with reply code 550, or downgrade the non-ASCII contents
   of all header bodies before continuing to send the message.  The
   downgrade process involve with a new ALT-ADDRESS parameter.  When
   downgrade occurs, the ALT-ADDRESS will be used for mail delivery
   instead of the internationalized email address, the detail is
   described in [EAI-downgrading].

Yeh                      Expires April 26, 2007                 [Page 8]

Internet-Draft             I18N Email Headers               October 2006

   angle-addr     =  [CFWS] "<" utf8-addr-spec [alt-address] ">" [CFWS]

   utf8-addr-spec =  utf8-local-part "@" utf8-domain

   utf8-local-part=  utf8-dot-atom / quoted-string / obs-local-part

   utf8-domain    =  utf8-dot-atom / domain-literal / obs-domain

   alt-address    =  [CFWS] "[" addr-spec "]" [CFWS]

   Below list a few possible <mailbox> representation as example.

      "DISPLAY_NAME" <ASCII@ASCII>
         ; traditional mailbox format

      "DISPLAY_NAME" <non-ASCII@non-ASCII>
         ; UTF8SMTP but no ALT-ADDRESS parameter provided,
         ; message will bounce if UTF8SMTP extension is not supported

      "DISPLAY_NAME" <non-ASCII@non-ASCII [ASCII@ASCII]>
         ; UTF8SMTP with ALT-ADDRESS parameter provided,
         ; ALT-ADDRESS can be used if downgrade is necessary
</quote>

---

From: Soobok Lee <[email-masked]>
Date: Tue, 30 Jan 2007 09:29:55 +0900

On Tue, Jan 30, 2007 at 09:06:17AM +0900, Soobok Lee wrote:
> mailbox         =       name-addr / utf8-addr-spec  <----

Some one may argue that "addr-spec" can be omitted because
addr-spec is a subset of utf8-addr-spec.

[utf8headers] does not redefine "mailbox" while it does "angle-addr".

Soobok

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 29 Jan 2007 19:37:51 -0800

--On 29. januar 2007 19:08 +0900 Soobok Lee <[email-masked]> wrote:

>
> RFC822 allowed 1) below and its successor RFC2822 required angled-address
> like 0). But, still we see <>-omitted 1) is popular in headers.
>

I'm happy with not allowing cases 13 and 15 in the UTF8SMTP ABNF.

Let the nonconformant UTF8SMTP UA implementations fail as they may.

           Harald

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 Jan 2007 07:58:23 -0500

--On Monday, 29 January, 2007 19:37 -0800 Harald Tveit

> I'm happy with not allowing cases 13 and 15 in the UTF8SMTP

Note that (13), as written, would be invalid under 2821 rules.
Either it would have to be interpreted as equivalent to
  To: <mailbox> <mailbox>
willl is invalid without a comma.   Or, because of the "@" the
first string would need to be quoted, i.e., as 
   To: "eas@domain" <ascii@domain>
Modulo accepting the UTF-8 in what then is a quoted name-phrase
("personal name"), MUAs need to support this anyway to support
    "My Personal non-ascii Name" <ascii@address> 
and it is not, in any sense unusual.  There is even a specific
downgrade, to encoded words in the personal name.

I have mixed feelings, for aesthetic and historical reasons,
about prohibiting (15).  I won't personally lose any sleep over
it, but predict that, in practice, some MUAs will display it and
permit is in input and then will make mistakes and let it leak.
If these then appear in headers, robustness will take over at
the other end.  So, I predict, we will end up with fairly broad
support for it whether we prohibit and/or mandate it or not.
The only case in which an unbracketed mailbox clearly needs to
be prohibited is when an alt-address appears.  So:
Interpreting 
    eai@domain  as equivalent to <eai@domain>    and
    Personal name <eai@domain>
all seem safe and historically reasonable (with Personal name
quoted if it contains any troublesome characters*), but there is
no permitted form that contains an alt-address that does not
have the entire address bracketed.

* The one issue I see here is that, if unbracketed addresses are
to be permitted (i.e., case 15 with personal names), then
UTF8-headers is going to need to be very specific about what
constitutes a "Special" in the non-ASCII space.  As we have
discovered while working on IDNAbis, that is not likely to be
especially easy and the list will grow over time.  And _that_,
it seems to me, is the strongest argument for simply prohibiting
case 15 and seeing where it gets us.

      john

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 30 Jan 2007 19:06:00 -0000

>> And utf8headers permits (I hope) both of those,
I think it is clear that we don't want (13) (we have carefully arranged  
that alt-addresses always occur inside of <...>. However, I think (15) is  
needed, simply in order to make eai@address (with no alt) be as similar as  
possible to the present ascii@address.
> that explicitly allows  15) .

No, it seems not.

> mailbox         =       name-addr / addr-spec / utf8-addr-spec  <----

Yes, I think that is what is needed.

Note also that there are some other bugs in that area of the syntax that  
need fixing, as I reported on 21st Dec.

---

From: Soobok Lee <[email-masked]>
Date: Wed, 31 Jan 2007 08:34:09 +0900

On Tue, Jan 30, 2007 at 07:06:00PM -0000, Charles Lindsey wrote:
> that alt-addresses always occur inside of <...>. 

I agree that we don't need 13) for EAI. 

But, anyway, old email address parsers  will  recognize  13) as   
   "eai@address" <ascii@address> 
because double quotation marks are often omitted from display name parts and 
parsers have done well with this for "robustness".

Even this WG email header  has : "To: IMA <[email-masked]>".
IMA has no double quotations marks surrounding it.

Most MUAs' cheking of input of 13) into headers won't produce errors, 
and programmers may not notice their mistakes.

Soobok

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

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 Jan 2007 18:45:31 -0500

--On Wednesday, 31 January, 2007 08:34 +0900 Soobok Lee
<[email-masked]> wrote:

> But, anyway, old email address parsers  will  recognize  13)
> as       "eai@address" <ascii@address> 
> because double quotation marks are often omitted from display
> name parts and  parsers have done well with this for
> "robustness".

I think you will find that none of them accept an unquoted
personal string containing an "@"-sign and will treat it as a
personal name.    If that "@" is there, even the most liberal of
systems will treat that case as either an error or as two
addresses.

> IMA has no double quotations marks surrounding it.

Sigh.  Quotation marks have never been required, or even
recommended in that case.  For your amusement, the exact rule is
the reason why I stopped using a period after the "C" in "John C
Klensin", which doesn't use quotation marks either.  I suggest
that you might find reading the specification useful.

> Most MUAs' cheking of input of 13) into headers won't produce
> errors,  and programmers may not notice their mistakes.

See above.

    john

---

From: Soobok Lee <[email-masked]>
Date: Wed, 31 Jan 2007 09:21:30 +0900

> systems will treat that case as either an error or as two

I have not tested every email address parser, but 
with my favorite PERL email address parser, I found this.

#!/usr/bin/perl
use Mail::Address;

$line=[email-masked] <[email-masked]>';

my @addrs = Mail::Address->parse($line);

foreach $addr (@addrs) {
       print "PHRASE: ", $addr->phrase,"\n";
       print "ADDRESS: ", $addr->address,"\n";
}
# output
PHRASE: 한글 @ 도메인 . tld
ADDRESS: [email-masked] 

> that you might find reading the specification useful.

You are right. I have bad habits of relying on my limited 
knowledge rather than on careful reading of specifications. 
I will correct that.

Unquoted word streams can be a valid display-name.
But, i can't find any rules that exclude "@" from part of 
display-name.

<quote from rfc2822>
address         =       mailbox / group

mailbox         =       name-addr / addr-spec

.....

display-name    =       phrase

.....

phrase          =       1*word / obs-phrase

word            =       atom / quoted-string          <-----------

....

obs-phrase      =       word *(word / "." / CFWS)

....

quoted-string   =       [CFWS]
                        DQUOTE *([FWS] qcontent) [FWS] DQUOTE
                        [CFWS]
</quote>

(these syntax rules are scattered around rfc2822 draft).

Soobok

---

From: Soobok Lee <[email-masked]>
Date: Wed, 31 Jan 2007 10:00:32 +0900

On Wed, Jan 31, 2007 at 09:21:30AM +0900, Soobok Lee wrote:
> Unquoted word stream  can be a valid display-name.

<quote from rfc2822>
atext           =       ALPHA / DIGIT / ; Any character except controls,
                        "!" / "#" /     ;  SP, and specials.
                        "$" / "%" /     ;  Used for atoms
                        "&" / "'" /
                        "*" / "+" /
                        "-" / "/" /
                        "=" / "?" /
                        "^" / "_" /
                        "`" / "{" /
                        "|" / "}" /
                        "~"

atom            =       [CFWS] 1*atext [CFWS]

dot-atom        =       [CFWS] dot-atom-text [CFWS]

dot-atom-text   =       1*atext *("." 1*atext)

.....

qtext           =       NO-WS-CTL /     ; Non white space controls

                        %d33 /          ; The rest of the US-ASCII
                        %d35-91 /       ;  characters not including "\"
                        %d93-126        ;  or the quote character

qcontent        =       qtext / quoted-pair

quoted-string   =       [CFWS]

</quote>

It's clear that "atom" cannot contain "@" while "qcontent" can contain "@".

So, if my reading of rfc2822 is correct, @-containing phrase should be
put in double quotations.  In other words, according to rfc2822 syntax rules,

  eai@address <ascii@address>     : invalid 
  "eai@address" <ascii@address>   : valid 

Soobok

---

From: John C Klensin <[email-masked]>
Date: Tue, 30 Jan 2007 20:49:50 -0500

--On Wednesday, 31 January, 2007 10:00 +0900 Soobok Lee
<[email-masked]> wrote:

> 
> <quote from rfc2822>
> atext           =       ALPHA / DIGIT / ; Any character except
> controls,                         "!" / "#" /     ;  SP, and
> specials.                         "$" / "%" /     ;  Used for
> atoms                         "&" / "'" /
>                         "*" / "+" /
>                         "-" / "/" /
>                         "=" / "?" /
>                         "^" / "_" /
>                         "`" / "{" /
>                         "|" / "}" /
>                         "~"
> 
>                         %d33 /          ; The rest of the
> US-ASCII                         %d35-91 /       ;  characters
> not including "\"                         %d93-126        ;
> or the quote character
> 
> So, if my reading of rfc2822 is correct, @-containing phrase
> should be put in double quotations.  In other words, according
> to rfc2822 syntax rules,
> 

Yes, exactly... as long as all of "eai@address" are ASCII.  If
they are not, 2822, which is entirely about ASCII, requires the
contents of that qcontent be encoded words.    I know you know
that, but the notation about is a little unclear so, to be
completely precise...

Presumably, we are making up different rules about the contents
of that qcontent in messages with UTF-8 headers (I suppose we
will call that something like "uqcontent"), but the rule about
ASCII special characters should remain intact to avoid the
ambiguity that would otherwise occur in these cases.

    john

---

From: Soobok Lee <[email-masked]>
Date: Wed, 31 Jan 2007 11:09:58 +0900

> 21)   eai@address <ascii@address>     : invalid 
> 22)   "eai@address" <ascii@address>   : valid 

RFC2822's "qtext" definition does not allow non-ascii characters and 22) may be also
invalid if it is not in QuotedPrintable or etc, under RFC2822.

But, under [utf8headers], 22) is valid, since "qtext" is redefined to contain 
non-ascii UTF-8 encoded characters ( see below).
So, if EAI-capable MUAs treat  22) as valid one, some of them may treat 21)
as equivalent to 22) for "robustness" and permit, 
as my previous PERL (Mail::Address) parser example shows.

Soobok

<quote from [utf8headers]>
Yeh                      Expires April 26, 2007                 [Page 6]

   UTF8-xtra-char  =   UTF8-2 / UTF8-3 / UTF8-4
                   
   UTF8-2          =   %xC2-DF UTF8-tail
                   
   UTF8-3          =   %xE0 %xA0-BF UTF8-tail /
                       %xE1-EC 2(UTF8-tail) /
                       %xED %x80-9F UTF8-tail /
                       %xEE-EF 2(UTF8-tail)
                   
   UTF8-4          =   %xF0 %x90-BF 2(UTF8-tail) /
                       %xF1-F7 3(UTF8-tail)

   UTF8-tail       =   %x80-BF

   These are taken from FRC 3629, but kept in this document for reasons
   of convenience.
   [Note in draft: Weather normalizing is needed or not will be place in
   here.]
   
6.2.  Syntax extend from RFC 2822
   
   The following rules are intended to extend the corresponding rules in
   RFC 2822 to allow UTF8 characters.
   
   ctext   =  NO-WS-CTL /     ; all of <text> except
              %d33-39 /       ; SP, HTAB, "(", ")"
              %d42-91 /       ; and "\"
              %d93-126 / 
              UTF8-xtra-char
   
   qtext   =       NO-WS-CTL /     ; all of <text> except
              %d33 /               ; The rest of the US-ASCII
              %d35-91 /        ; characters not including "\"
              %d93-126 /       ; or the quote character
              UTF8-xtra-char           <---------------------

...

   utf8-atext   =  ALPHA / DIGIT / 
                   "!" / "#" /     ; Any character except
                   "$" / "%" /     ; controls, SP, and specials.
                   "&" / "'" /     ; Used for atoms
                   "*" / "+" /
                   "-" / "/" /
                   "=" / "?" /
                   "^" / "_" /
                   "`" / "{" /
                   "|" / "}" /
                   "~" /
                   UTF8-xtra-char        <------------------
   
   utf8-atom     = [CFWS] 1*utf8-atext [CFWS]
   
   utf8-dot-atom = [CFWS] utf8-dot-atom-text [CFWS]
   
   utf8-dot-atom-text = 1*utf8-atext *("." 1*utf8-atext)
</quote>

---

From: Jeff Yeh <[email-masked]>
Date: Wed, 31 Jan 2007 16:30:17 +0800

Charles Lindsey wrote:
> that alt-addresses always occur inside of <...>. However, I think (15) 
> is needed, simply in order to make eai@address (with no alt) be as 
> similar as possible to the present ascii@address.

Speak as the editor of utf8header, my intension is not to allow 13 and 
15. As discussed in previous posts, I think it makes sense that 15 is 
allowed as we use ascii@address right now.

>> mailbox         =       name-addr / addr-spec / utf8-addr-spec  <----

Thanks, this will be added, see above.

I'm personally prefer <eai@address [ascii@address]> just for good 
looking reason (and also easier parsing with RE, for me). Making fewer 
confusing on the address representation. But I don't have strong reason 
to against <eai@address <ascii@address>> at this point.

Regards,

Jeff Yeh
-TWNIC

---

From: Tony Finch <[email-masked]>
Date: Wed, 31 Jan 2007 14:42:08 +0000

On Wed, 31 Jan 2007, Jeff Yeh wrote:
>
> I'm personally prefer <eai@address [ascii@address]> just for good looking
> reason (and also easier parsing with RE, for me). Making fewer confusing on
> the address representation. But I don't have strong reason to against
> <eai@address <ascii@address>> at this point.

I agree with you and Soobok Lee on this matter.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
VIKING NORTH UTSIRE SOUTH UTSIRE FORTIES: WEST OR SOUTHWEST 7 TO SEVERE GALE
9, VEERING NORTHWEST 5 OR 6, BACKING SOUTHWEST 4 FOR A TIME. ROUGH OR VERY
ROUGH, OCCASIONALLY MODERATE LATER. RAIN AT TIMES. GOOD, OCCASIONALLY MODERATE
OR POOR.

---

From: Kari Hurtta <[email-masked]>
Date: 31 Jan 2007 17:11:12 +0200

> systems will treat that case as either an error or as two

Seems that my MUA does accept eai@address as phrase  
('<' is actual trigger, not '@' ).  So your claim is wrong 
(about "none" part).

/ Kari Hurtta

hurtta@Hurtta06k:~$ cat X
>From xx Wed Jan 31 17:02:11 EET 2007
From: eai@address <ascii@address>

hurtta@Hurtta06k:~$

Display: ------------------------------------------------
Message 1/1 eai @ address <ascii@address>          Jan 31, 2007 05:02:11 pm EET
>From xx Wed Jan 31 17:02:11 EET 2007
From: eai @ address <ascii@address>

--------------------------------------------------------

Debug output: ----------------------------------------------

                        ----- Message 1 -----

Lines: 4                Status: A  C  D  E  N  P  T  U  V  O  R  M  P  U  N
Content-Length: 0               c  o  e  x  e  r  a  r  i  l  e  i  r  s  H
Binary: 0                       t  n  l  p w  i  g  g  s  d  p  m  e  u  d
'From ' on body: 0              n  f  d  d     v  d  n  i     l  e  M  p  r

Offset: 0                       0  0  0  0  0  0  0  0  1  0  0  0  0  0  1  0

Received on: Wed Jan 31 17:02:11 2007
Message sent on: Wed Jan 31 17:02:11 2007

>From timezone: EET (7200)
(Env) From: xx
From: eai @ address                  <ascii@address>
Subject:
Internal Index Reference Number = 0/0 (hdr index 1)
Thread number = -1
Message-ID: <none>
Status:
Content-Transfer-Encoding: 7bit
----------------------------------------------------------

Debug output actually says that phrase was "eai @ address"
and address was "ascii@address".

Also reply shows same: 

hurtta@Hurtta06k:~$ cat Canceled.mail.dir/13544-43.Canceled.mail
Subject: Re: your mail
To: "eai @ address" <ascii@address>
Date: Wed, 31 Jan 2007 17:06:12 +0200 (EET)
Sender: hurtta
From: Kari Hurtta <Kari.Hurtta@CENSORED>
Content-Length: 31
Status: RO

eai @ address <ascii@address>:
hurtta@Hurtta06k:~$

---

From: John C Klensin <[email-masked]>
Date: Wed, 31 Jan 2007 11:40:51 -0500

--On Wednesday, 31 January, 2007 17:11 +0200 Kari Hurtta
<[email-masked]> wrote:

>> personal name.    If that "@" is there, even the most liberal
>> of systems will treat that case as either an error or as two
>> addresses.
> 

Does this mean that you must specify brackets to have an
address?  If so, while MUAs are free to do as they like, the
intent and guidance of the standard is certainly being ignored.
And, of course, if they send that out on the net without quotes,
they are in violation of the spec.

But I stand corrected.  "none" should have been "very few".

    john

---

From: Kari Hurtta <[email-masked]>
Date: 31 Jan 2007 18:58:40 +0200

> address?  If so, while MUAs are free to do as they like, the

No.

> they are in violation of the spec.

In reply phrase was quoted on my example.
 
> But I stand corrected.  "none" should have been "very few".

Left hand side of '<' is treated as phrase.

If there is no '<' or ':', it is address.
Left hand side of ':' is also phrase (if not inside of '<' and '>'
tokens.)

( Tokens ':' '<' '>' ',' ';'  (and end of string) are which are looked 
  for by parser.  Line is first tokenized. ) 

/ Kari Hurtta

---

From: Kari Hurtta <[email-masked]>
Date: 31 Jan 2007 19:03:56 +0200

> Left hand side of ':' is also phrase (if not inside of '<' and '>'

Hmm. Actually group phrase is ignored.

/ Kari Hurtta

---

From: John C Klensin <[email-masked]>
Date: Wed, 31 Jan 2007 12:06:52 -0500

--On Wednesday, 31 January, 2007 18:58 +0200 Kari Hurtta
<[email-masked]> wrote:

>> >> personal string containing an "@"-sign and will treat it
>> >> as a personal name.    If that "@" is there, even the most
>> >> liberal of systems will treat that case as either an error
>> >> or as two addresses.
>> > 
>> intent and guidance of the standard is certainly being
>> ignored. And, of course, if they send that out on the net
>> without quotes, they are in violation of the spec.
> 
> Left hand side of ':' is also phrase (if not inside of '<' and
> '>' tokens.)
> 
> ( Tokens ':' '<' '>' ',' ';'  (and end of string) are which
> are looked    for by parser.  Line is first tokenized. ) 

Within an MUA, that certainly works.  Not to my taste, but UI
behavior is, after all, a matter of taste.

    john

---

From: Soobok Lee <[email-masked]>
Date: Thu, 1 Feb 2007 11:41:31 +0900

> behavior is, after all, a matter of taste.

I made manually a message file which contains unquoted eai@address
as below.
You can save the next rfc2822 message into a mbox file "/tmp/mbx1"  
and open it using "mutt -f /tmp/mbx1" (or elm,pine etc) and then 
try to make reply-all.  If your MUAs is "robust",
you will see quotations marks are added around CC's name_parts below 
in the reply form.

<quote>
>From [email-masked] Thu Feb  1 10:23:14 2007
Received: from nobody.com (localhost [127.0.0.1])
        by ns5.lsb.org (8.13.0.PreAlpha4/8.13.0.PreAlpha4) with ESMTP id l111NEJ5015951
        for <[email-masked]>; Thu, 1 Feb 2007 10:23:14 +0900
Date: Thu, 1 Feb 2007 10:23:14 +0900
Message-Id: <[email-masked]>
From: "Soobok Lee" <[email-masked]>
To: "Soobok Lee" <[email-masked]>
Cc: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [EAI] other thought about <eai@address <ascii@address>>

This email is a test.

</quote>

This is a mutt1.4  screenshot when I tried reply-all to the above message.
<quote>
:보냄  q:취소  t:To  c:CC  s:Subj  a:파일 첨부  d:설명  ?:도움말                                                                   
    From: Soobok Lee <[email-masked]>
      To: Soobok Lee <[email-masked]>
      Cc: "한글 @ 도메인. tld" <[email-masked]>, "ASCII @ DOMAIN. tld" <[email-masked]>
     Bcc:
 Subject: Re: [EAI] other thought about <eai@address <ascii@address>>
Reply-To:
     Fcc: /home/lsb/Sent
     PGP: 없음

-- 첨부물                                                                                                                            
- I     1 /tmp/mutt-ns5-28332-1                                                                  [text/plain, 7bit, us-ascii, 0.1K] 

</quote>

I found  either sendmail 8.13.0 process or its procmail component  
  (I don't know which of them exactly) might transform
  eai@address <ascii@address> in the headers into 
 "eai@address"<ascii@address>  before saving the received message 
  into the mailbox.

If you have time, you can replace From/TO addresses in the example message 
with your email address , and feed it into your sendmail process.

Soobok

---

From: Kari Hurtta <[email-masked]>
Date: 01 Feb 2007 06:41:39 +0200

> behavior is, after all, a matter of taste.

How else header can be parsed?   Remember: On here parser is possibly
parsing mails which are local on unux. They are newer passed via
SMTP. On some configurations there is no '@' on address at all.

On local mail you can have:

From:  Name <account>

From: account

From: account (Name)

There is no @ -character.

/ Kari Hurtta