Subject: [EAI] localprep and pop3 with saslprep username authetication

From: Soobok Lee <[email-masked]>
Date: Mon, 4 Dec 2006 13:50:13 +0900

Hi,

This is another thread derived from localprep vs local decision subject.

If future EAI-capable pop3 MUA clients use  saslprep-based authentication 
for username (which is the same with localpart mailbox name) comparison,
Do we have any other choice but to accept saslprep as subset of
localprep or saslprep==localprep?

Or, should we request EAI-capable MUA vendors that only localprep be 
used for username preparation for authentication ?

this is the saslprep RFC's url: 

 http://www.ietf.org/rfc/rfc4013.txt

Soobok Lee

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

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 04 Dec 2006 08:02:05 +0100

> for username (which is the same with localpart mailbox name) comparison,

False in general. My POP/IMAP mailbox name is "hta", while my normal email 
address is "[email-masked]". There's no link between the two required 
by any protocol.

> used for username preparation for authentication ?

Do you mean "request" (offer advice) or "require" (make the standard 
specify that it has to be that way)?

note: saslprep does not have a punycode stage. The result of saslprep is an 
UTF-8 string.

---

From: Soobok Lee <[email-masked]>
Date: Mon, 4 Dec 2006 19:02:03 +0900

> address is "[email-masked]". There's no link between the two required 

I agree with your that username and its localpart may be different in certain installations.
But, in @yahoo.com and @hotmail.com , the localpart(or entire email addresses) 
is the username.  that is very common, though not true in every case.

When entire email address is used as username, that would complicate 
preparation job, because  localpart should be prepared by localprep, 
while hostname part  should be  done by nameprep.

> specify that it has to be that way)?

For pop3 authentication,
in the case where username==localpart, I think "require localprep" is the answer.
in the case where username!=localpart, I think "request for cautions" is the answer.

But, pop3 MUA clients have no clue about whether its assinged pop3 server host has 
username==localpart rule or not.

So, we have no other choice but "require localprep".

> note: saslprep does not have a punycode stage. The result of saslprep is an 

This discustion is not meant directly for ACE-encoding. 
Under assumption that even utf8 localpart may need some normalization work. 

My question is that: if we "require" localprep to be applied to localparts,
is this defining some syntactical rules over localparts and against
"local decision principles/traditions" ?

Soobok

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 04 Dec 2006 11:14:03 +0100

> So, we have no other choice but "require localprep".
Yes, we have another choice.

Don't define a localprep, and leave it as a local matter, just like the 
specs currently say.

---

From: Soobok Lee <[email-masked]>
Date: Mon, 4 Dec 2006 19:27:19 +0900

On Mon, Dec 04, 2006 at 11:14:03AM +0100, Harald Alvestrand wrote:
> >But, pop3 MUA clients have no clue about whether its assinged pop3 server 
> >host has username==localpart rule or not.
> >

Yet another choice:
  Define a localprep, leave its adoption as a local matter.

Soobok

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 04 Dec 2006 11:29:31 +0100

--On 4. desember 2006 19:27 +0900 Soobok Lee <[email-masked]> wrote:

>> > But, pop3 MUA clients have no clue about whether its assinged pop3
>> > server  host has username==localpart rule or not.
>> >
If its adoption is a local matter, it is not required.

---

From: Soobok Lee <[email-masked]>
Date: Mon, 4 Dec 2006 19:31:07 +0900

> If its adoption is a local matter, it is not required.

Yes. Its application will be just an advice, not a requirement.

Soobok

---

From: Soobok Lee <[email-masked]>
Date: Mon, 4 Dec 2006 20:00:15 +0900

this is for clarification of the past issues under the assumption  that 

> > >>> in the case where username==localpart, I think "require localprep" is

 In this case where username==localpart && localprep is NOT applied by local decision, 
 if pop3 clients preprocess using "saslprep" for username authentication,
 there may be a possiblilty that saslprep(username)!=username and login 
 attempt fails. But, this is a local issue and the local site admin
 should be aware of this possiblity and optionally can manage to add
 "dual username accounts" that are mapped to single mailbox(localpart).

> > >>> in the case where username!=localpart, I think "request for cautions"

In this case where username may not always be equal to localpart,
  saslprep(username) for authentication is irrelevant to our localprep 
  for localparts issue. it is just a local authentication issue.

Soobok

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 06 Dec 2006 13:16:44 -0000

> specify that it has to be that way)?

Well there is also an intermediate option, which is "recommend" (aka
SHOULD).

If you type é on your keyboard, then your operating system or MUA or
whatever is 99.999% likely to give you e' rather than e+. In fact,
generating e+ from your keyboard probably requires technical skills beyond
the average user. So a domain owner who permits e+ in a local-part of an
address in his system is going to find that people worldwide are going to
have great difficulty communicating with him.

So much so, that you can well argue that it is a matter of
interoperability, and hence SHOULD (and maybe even MUST, but I will settle
for SHOULD) is justified. If that is accepted, then the next question is
where you apply it.

At the minimum you would say that domains allocating local-parts to their
users SHOULD make them NFC-compatible (or else normalize them on receipt).

You might also say that MUAs when composing addreseses SHOULD make them
NFC-compatible, but that is likely to be their default behaviour anyway.
That also accords with the Unicode tradition of "early normalization". For
sure, all intermediate MTAs should pass on exactly what they receive. You
might argue that if an MUA sees an e+ in a Reply-To, it should reply to
exactly what it sees.

Anf finally, if you are making such a rule, then you can choose between
NFC, NFKC, saslprep or some other localprep.

And finally, if it is a SHOULD rather than a MUST, then the script kiddies
can have fun by using non-normalized local-parts by mutual agreement, so
that us adults will have difficulty communicating with them.

-- 
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: Soobok Lee <[email-masked]>
Date: Wed, 6 Dec 2006 22:54:13 +0900

On Wed, Dec 06, 2006 at 01:16:44PM -0000, Charles Lindsey wrote:
> ....

I also prefer SHOULD  to MUST or MAY. If we use "MUST", it would force
syntaxes over localparts.

> That also accords with the Unicode tradition of "early normalization". 

Do you have any tech reports (utc) known about this "early normaliation" ?

> For sure, all intermediate MTAs should pass on exactly what they receive. You

If MUA implementation shares the same email address postprocessing routines for 
replying and composing, their may be no way to "reply to exactly what it 
sees". I can't imagine MUA architects normalized differently for reply-to sender
address and typed/addrbooked recipient addresses. "All or nothing" seems
simpler to me.

> NFC, NFKC, saslprep or some other localprep.

Are you suggesting that our draft enumerate those alternatives and recommend
them to choose one among them ?  Or, should we designate single most preferrable
one in our draft ?

> that us adults will have difficulty communicating with them.

Yes. it will allow rooms for other normailzation or no normalization.

Soobok