headers
Yangwoo Ko | 1 Dec 2006 02:16
Picon

Re: [EAI] i18n of localpart versus i18n of email RFC standards


Soobok Lee wrote:
> 
> Hi, All
> 
> After looking into EAI drafts, I find this WG had been focusing on
>  18n(utf8-ization) of all Email related RFC standards, 
>  rather than  defining ACE-encoding standard for non-ascii localpart.
>  I can guess and accept the reason behind the former approach, but
>  i still believe the latter approach has some merits and even co-exist
>  with the cureent EAI framework.

Please be careful about the current charter of EAI WG.
It is clearly focused on "an" approach that is described
in framework document. If you want to pursue other approach,
you may need another WG.

> 1. 
> The framework document does not exclude the use of 
> proprietary (home-made) localpart ACE encoding per host basis, but
> this WG has no nameprep-like stringprep profile draft for localpart 
> ACE encoding yet. Do It Yourself policy ? :-) 
> 
> If we need and call it "localprep", it'll be almost the exact
> copy of nameprep RFC with  addition of expanded delimiters set and 
> email-specific security considerations and suggestion of x?-- prefix.
> This encoding clearly has some limitations and may not be "MUST USE" 
> for every host, but will help fast adoption of EAI for some parties, 
> especially for major email portals who can accept the limitations.
> the nameprep with more delimiters(,=/_ etc) would be enough for
(Continue reading)

Permalink | Reply | 13 comments |
headers
Soobok Lee | 1 Dec 2006 02:22

Re: [EAI] i18n of localpart versus i18n of email RFC standards

On Thu, Nov 30, 2006 at 11:08:34PM +0100, Harald Alvestrand wrote:
> Soobok Lee wrote:
> >Hi, All
> >
> >After looking into EAI drafts, I find this WG had been focusing on
> > 18n(utf8-ization) of all Email related RFC standards, 
> > rather than  defining ACE-encoding standard for non-ascii localpart.
> > I can guess and accept the reason behind the former approach, but
> > i still believe the latter approach has some merits and even co-exist
> > with the cureent EAI framework.
> >  
> It is, however, not the approach this WG is chartered to follow, and 
> discussion is therefore out of scope for this WG.

I understand your concern as the chair.

But, when alt-address parameter is not given by MUA or not available at all,
downgrading MUA/MTA may favor some default ACE-encoding for localparts,
over just bouncing back or rejecting. 
and if we agree that such default auto-converint ACE encoding is useful,
this will support that ACE-encoding job falls within this WG scope.

Moreover, current un-authenticated alt-address binding may cause some spoofing
problem which has different nature than that of ascii-only email address,
so default ace-encoding has some merits from security viewpoints.
This is the second reason why i believe default ace encoding falls 
within this WG.

Of course, such ACE-encoding may be used not only for downgrading
but also for the early composing stage in MUA, but, this latter
(Continue reading)

Permalink | Reply | 0 comments |
headers
Soobok Lee | 1 Dec 2006 02:31

Re: [EAI] i18n of localpart versus i18n of email RFC standards

On Fri, Dec 01, 2006 at 10:16:47AM +0900, Yangwoo Ko wrote:
> 
> Soobok Lee wrote:
> >
> >Hi, All
> >
> >After looking into EAI drafts, I find this WG had been focusing on
> > 18n(utf8-ization) of all Email related RFC standards, 
> > rather than  defining ACE-encoding standard for non-ascii localpart.
> > I can guess and accept the reason behind the former approach, but
> > i still believe the latter approach has some merits and even co-exist
> > with the cureent EAI framework.
> 
> Please be careful about the current charter of EAI WG.
> It is clearly focused on "an" approach that is described
> in framework document. If you want to pursue other approach,
> you may need another WG.

I understand, but the problem is on "time". :-)

> 
> >1. 
> >The framework document does not exclude the use of 
> >proprietary (home-made) localpart ACE encoding per host basis, but
> >this WG has no nameprep-like stringprep profile draft for localpart 
> >ACE encoding yet. Do It Yourself policy ? :-) 
> >
> >If we need and call it "localprep", it'll be almost the exact
> >copy of nameprep RFC with  addition of expanded delimiters set and 
> >email-specific security considerations and suggestion of x?-- prefix.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yao Jiankang | 1 Dec 2006 02:48
Picon

Re: [EAI] i18n of localpart versus i18n of email RFC standards


----- Original Message ----- 
From: "Soobok Lee" <lsb <at> lsb.org>
To: "Harald Alvestrand" <harald <at> alvestrand.no>
Cc: <ima <at> ietf.org>
Sent: Friday, December 01, 2006 9:22 AM
Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards


> On Thu, Nov 30, 2006 at 11:08:34PM +0100, Harald Alvestrand wrote:
>> Soobok Lee wrote:
>> >Hi, All
>> >
>> >After looking into EAI drafts, I find this WG had been focusing on
>> > 18n(utf8-ization) of all Email related RFC standards, 
>> > rather than  defining ACE-encoding standard for non-ascii localpart.
>> > I can guess and accept the reason behind the former approach, but
>> > i still believe the latter approach has some merits and even co-exist
>> > with the cureent EAI framework.
>> >  
>> It is, however, not the approach this WG is chartered to follow, and 
>> discussion is therefore out of scope for this WG.
> 
> I understand your concern as the chair.
> 
> But, when alt-address parameter is not given by MUA or not available at all,
> downgrading MUA/MTA may favor some default ACE-encoding for localparts,
> over just bouncing back or rejecting.

on such occasions,  bouncing back  is a good choice.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Soobok Lee | 1 Dec 2006 03:35

Re: [EAI] i18n of localpart versus i18n of email RFC standards

On Fri, Dec 01, 2006 at 09:48:03AM +0800, Yao Jiankang wrote:
> 
> > But, when alt-address parameter is not given by MUA or not available at all,
> > downgrading MUA/MTA may favor some default ACE-encoding for localparts,
> > over just bouncing back or rejecting.
> 
> on such occasions,  bouncing back  is a good choice.
> ACE-encoding on the local parts will cause a lot of potential problems, which has been discussed a lot on
this mailing list and many drafts.
> ACE-encoding is ugly to users. if some MUA/MTA is sure that some UTF-8 address can be safely transformed
into ACE-address without losing any information,
> these MUA/MTA may select their own version of ACE-address.

As your [smtpext] section 2.5 stated, 
<quote>
   Some may prefer transformed the non-ASCII address to the ASCII
   Compatible Encoding(ACE) address as the value of the ALT-ADDRESS.
   The big problem with applying an ACE to all local-parts is that the
   sending or converting system doesn't know if there are some specific
   data or instructions embedded in the address that the ACE process
   would hide.  Some SMTP servers may depend on these specific data or
   instructions to do some operations while the local parts applied with
   ACE will lose or hide these data or instructions. 
</quote>

How about having some guideline to *ban* on embedding any data/instruction
into the NON-ASCII localpart, since  NON-ASCII lables are most for humans
not for machines. They will use ASCII localpart for that purpose. No harm
at all.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yao Jiankang | 1 Dec 2006 04:17
Picon

Re: [EAI] i18n of localpart versus i18n of email RFC standards


----- Original Message ----- 
From: "Soobok Lee" <lsb <at> lsb.org>
To: "Yao Jiankang" <yaojk <at> cnnic.cn>
Cc: <ima <at> ietf.org>; "Harald Alvestrand" <harald <at> alvestrand.no>
Sent: Friday, December 01, 2006 10:35 AM
Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards


> On Fri, Dec 01, 2006 at 09:48:03AM +0800, Yao Jiankang wrote:
>> 
>> > But, when alt-address parameter is not given by MUA or not available at all,
>> > downgrading MUA/MTA may favor some default ACE-encoding for localparts,
>> > over just bouncing back or rejecting.
>> 
>> on such occasions,  bouncing back  is a good choice.
>> ACE-encoding on the local parts will cause a lot of potential problems, which has been discussed a lot on
this mailing list and many drafts.
>> ACE-encoding is ugly to users. if some MUA/MTA is sure that some UTF-8 address can be safely transformed
into ACE-address without losing any information,
>> these MUA/MTA may select their own version of ACE-address.
> 
> 
> As your [smtpext] section 2.5 stated, 
> <quote>
>   Some may prefer transformed the non-ASCII address to the ASCII
>   Compatible Encoding(ACE) address as the value of the ALT-ADDRESS.
>   The big problem with applying an ACE to all local-parts is that the
>   sending or converting system doesn't know if there are some specific
>   data or instructions embedded in the address that the ACE process
(Continue reading)

Permalink | Reply | 0 comments |
headers
Soobok Lee | 1 Dec 2006 05:29

Re: [EAI] i18n of localpart versus i18n of email RFC standards

On Fri, Dec 01, 2006 at 11:17:36AM +0800, Yao Jiankang wrote:
> 
> ----- Original Message ----- 
> > 
> > How about having some guideline to *ban* on embedding any data/instruction
> > into the NON-ASCII localpart, since  NON-ASCII lables are most for humans
> > not for machines. They will use ASCII localpart for that purpose. No harm
> > at all.
> 
> yes, I also considered this issue about *ban* on embedding any data/instruction
>  into the NON-ASCII localpart before.
> on another thought, *ban" will also cause some problems and has some inconvenience.
> for example, I can use sub-address such as yao+ietf <at> organization.com before  EAI protocol is published.
> but I can not use sub-address such as [Chinese Character yao]+ietf <at> IDN after  EAI protocol is published.
> 
> so after EAI protocols are published, it is not our design aim that  some email address form will be
dis-allowed. 

in your example, "+" can be added as a legal delimiter for localparts. /=_! can be added as legal delimiters likewise.
For my example, "[SOOBOK in UTF8].[LEE in UTF8]+eai_ietf <at> lsb.org can be autoconverted into
"xn--sbsbsbs.xn--lelelele+eai_ietf <at> lsb.org. No loss of information. dot and + and underbar was not lost.
The receiving SMTP server parses it back to NONASCII in order to find data/instruction
for whitelisting filtering. Even the receiving server can work directly
on xn--******+eai_ietf <at> lsb.org   without NON-ASCII version if it is already registered
as an ascii *alias* for NON_ASCII in the server alias database.  
Still I can find no problem at all.

> 
> 
> >
(Continue reading)

Permalink | Reply | 1 comment |
headers
abel | 1 Dec 2006 08:25
Picon

Re: [EAI] i18n of localpart versus i18n of email RFC standards


----- Original Message ----- 
From: "Soobok Lee" <lsb <at> lsb.org>
To: "Yao Jiankang" <yaojk <at> cnnic.cn>
Cc: <ima <at> ietf.org>
Sent: Friday, December 01, 2006 12:29 PM
Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards

> On Fri, Dec 01, 2006 at 11:17:36AM +0800, Yao Jiankang wrote:
> >
> > ----- Original Message ----- 
> > >
> > > How about having some guideline to *ban* on embedding any
data/instruction
> > > into the NON-ASCII localpart, since  NON-ASCII lables are most for
humans
> > > not for machines. They will use ASCII localpart for that purpose. No
harm
> > > at all.
> >
> > yes, I also considered this issue about *ban* on embedding any
data/instruction
> >  into the NON-ASCII localpart before.
> > on another thought, *ban" will also cause some problems and has some
inconvenience.
> > for example, I can use sub-address such as yao+ietf <at> organization.com
before  EAI protocol is published.
> > but I can not use sub-address such as [Chinese Character yao]+ietf <at> IDN
after  EAI protocol is published.
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Yao Jiankang | 1 Dec 2006 08:33
Picon

Re: [EAI] i18n of localpart versus i18n of email RFC standards


----- Original Message ----- 
From: "abel" <abelyang <at> twnic.net.tw>
To: "Soobok Lee" <lsb <at> lsb.org>
Cc: <ima <at> ietf.org>
Sent: Friday, December 01, 2006 3:25 PM
Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards


> 
> ----- Original Message ----- 
> From: "Soobok Lee" <lsb <at> lsb.org>
> To: "Yao Jiankang" <yaojk <at> cnnic.cn>
> Cc: <ima <at> ietf.org>
> Sent: Friday, December 01, 2006 12:29 PM
> Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards
> 
> 
>> On Fri, Dec 01, 2006 at 11:17:36AM +0800, Yao Jiankang wrote:
>> >
>> > ----- Original Message ----- 
>> > >
>> > > How about having some guideline to *ban* on embedding any
> data/instruction
>> > > into the NON-ASCII localpart, since  NON-ASCII lables are most for
> humans
>> > > not for machines. They will use ASCII localpart for that purpose. No
> harm
>> > > at all.
>> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Soobok Lee | 1 Dec 2006 08:45

Re: [EAI] i18n of localpart versus i18n of email RFC standards

On Fri, Dec 01, 2006 at 03:33:06PM +0800, Yao Jiankang wrote:
> 
> >> in your example, "+" can be added as a legal delimiter for localparts.
> > /=_! can be added as legal delimiters likewise.
> >> For my example, "[SOOBOK in UTF8].[LEE in UTF8]+eai_ietf <at> lsb.org can be
> > autoconverted into
> >> "xn--sbsbsbs.xn--lelelele+eai_ietf <at> lsb.org. No loss of information. dot
> > and + and underbar was not lost.
> >> The receiving SMTP server parses it back to NONASCII in order to find
> > data/instruction
> >> for whitelisting filtering. Even the receiving server can work directly
> >> on xn--******+eai_ietf <at> lsb.org   without NON-ASCII version if it is
> > already registered
> >> as an ascii *alias* for NON_ASCII in the server alias database.
> >> Still I can find no problem at all.

> > I very agree Soobok views, But this was a violation of the framework
> > requirements.
> 
> Yes, it is a violation of the framework  requirements.
> 
> > Harald said: that's a local decision about automatic converting.
> > Even if there are delimters.
> 
> Agree. it is a local decision, not our protocol decision.
> 
> Yao Jiankang 
> > Abel

Can you suggest the exact paragraph in the framework or other drafts
(Continue reading)

Permalink | Reply | 0 comments |

Gmane