Subject: RFC 3280 error WRT rfc822Name

From: Steve Hanna <[email-masked]>
Date: Tue, 17 Sep 2002 17:23:52 -0400

In section 4.2.1.7, RFC 3280 (and RFC 2459) says:

   Note that while upper and lower case letters are allowed in an
   RFC 822 addr-spec, no significance is attached to the case.

But RFC 822 says:

        The only syntactic units which requires preservation of
        case information are:

                    -  text
                    -  qtext
                    -  dtext
                    -  ctext
                    -  quoted-pair
                    -  local-part, except "Postmaster"

        When matching any other syntactic unit, case is to be ignored.

And RFC 2821 (the successor to RFC 821 and the companion
to RFC 2822, which obsoletes RFC 822) is more explicit:

   The local-part of a mailbox MUST BE treated as case sensitive.

I have spoken to a few people about this and the consensus
seems to be that RFC 3280 is wrong. When matching email
addresses (such as when processing name constraints during
certificate path validation), the local-part component of
an email address must be treated as case-sensitive.

If the members of these lists don't agree with this analysis,
please speak up. Otherwise, I expect that this will be fixed
in the successor to RFC 3280. Note that I don't think this
is an especially big deal. I just thought people would want
to know of the problem ASAP.

Note also that many email servers don't treat local-part as
case-sensitive. But some do. There's no way for a certificate
processing system to know whether [email-masked] is
actually the same mailbox as [email-masked]. So the
certificate processing system must treat them as different.
At least, that's the rationale for this rule.

Thanks,

Steve Hanna
Sun Microsystems, Inc.

---

From: [email-masked] (Bill Burns)
Date: Tue, 17 Sep 2002 15:36:59 -0700

>At least, that's the rationale for this rule.
Thanks, Steve.

That's pretty interesting....I hope I'm the only one surprised by this 
requirement.  At the end of the same paragraph in RFC 2821 is the 
"loophole" that I think most people will invoke to get around this new 
"requirement":

...However, exploiting the case sensitivity of mailbox local-parts impedes interoperability and is discouraged.

I anticipate that this means, for all practical matters, that the "MUST" 
part of case sensitivity will be ignored by enough vendors that we 
should plan on treating the mail local-part as case insensitive anyhow. 
 Personally, I think it makes sense to treat mailbox strings as case 
insensitive, but that's just me speaking.

bill

---

From: [email-masked]
Date: Tue, 17 Sep 2002 16:27:58 -0700 (PDT)

> requirement.

This requirement is well understood by those of us who work on email software.
Any package that fails to support it gets in trouble sooner or later. Indeed,
software that preserves case but isn't capable of supporting case sensitivity
for domains it has administrative control over can be problematic. I've seen
software sales won or lost over this issue.

>  At the end of the same paragraph in RFC 2821 is the

> insensitive, but that's just me speaking.

The rule is fairly simple: If you have administrative authority for the domain
you are entitled to use the local-part in any way you like, including but not
limited to igoring case. If, on the other hand, you do not have administrative
authority, you are not entitled to do this. And if you do, know that there real
domain exist where case matters and things will break.

				Ned

---

From: "Marc Jadoul" <[email-masked]>
Date: Wed, 18 Sep 2002 10:41:56 +0200

Seems a BIG problem to me!

May be RFC 3280 is wrong in his understanding of RFC 822.
But RFC 822 (or ...) is probably wrong in doing things so complex for End
Users.
And I do not see how it can be fixed except fixing RFC 2822 and RFC 2821.

Why is it like this in RFC 822 and successor?

Marc Jadoul

---

From: Himanshu Chatterjee <[email-masked]>
Date: Wed, 18 Sep 2002 11:17:49 -0700

May be also an issue for those who depend on ldap 'mail' attribute and by
protocol ldap's data is case insensitive.  Himanshu

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 24 Sep 2002 13:32:20 -0700

>Why is it like this in RFC 822 and successor?

The original reason was backward compatibility. 822 (actually I think it 
was RFC 733) was designed to be compatible with a number of existing email 
systems (a very long time ago).

The reason it can't change is also backward compatibility. Such a change 
would cause any current conforming mail system that allows case-sensitive 
mailboxes to become non-conforming.

LL

---

From: "Marc Jadoul" <[email-masked]>
Date: Wed, 25 Sep 2002 12:10:06 +0200

Sometimes it is better to break things! Having 2 users with the same email
address except cases is really a stupid thing to do, and you won't break
that much by changing that! Seems more like fixing things to me.
Does it exist 1 real world example for having as requirement 'cases
sensitive email addresses'?

Actually I suppose (Please confirm if you know) that most smime clients will
choose the certificates to encrypt emails using a case insensitive matching
of the destination email addresses. There will be less problems if we change
RFC 282? than if we have to change all the smime clients and if we need to
teach to users to be carefull with cases in the first part of the email
address...

Regards,

Marc Jadoul

----- Original Message -----
From: "Laurence Lundblade" <[email-masked]>
To: "Marc Jadoul" <[email-masked]>; "Steve Hanna"
<[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, September 24, 2002 10:32 PM
Subject: Re: RFC 3280 error WRT rfc822Name

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 26 Sep 2002 09:46:06 -0700

At 12:10 PM 9/25/2002 +0200, Marc Jadoul wrote:

>Sometimes it is better to break things!

I agree that can be true, though you generally need a transition plan.

>Having 2 users with the same email
>address except cases is really a stupid thing to do,

That's probably true in general, but someone some where may have a 
non-stupid use. For example they have layered some application on top of 
email that involved user identification that is case sensitive and that 
application is one that can't be modified. Or maybe some one has a gateway 
to another mail system that is case sensitive.

>  and you won't break
>that much by changing that!

RFC-822 email addresses are used by more than 100 million users and 
thousands of products. These addresses are even used outside of email in 
things like SIP. Today the rules you follow for this particular part of the 
standard are clear.

If we were to change the rules to say that case doesn't matter then we 
should say that all software using these addresses should do comparisons 
independent of case. It would take years for all the currently deployed 
servers and clients to be upgraded to have that behavior. We'd probably 
never really get it straight. It would probably also take a few years to 
update RFC 2822.

>Seems more like fixing things to me.

Don't have a really good concrete example (which doesn't mean one doesn't 
exist). What I would offer is the fact that UNIX, Linux, and Solaris login 
names are case sensitive even though sendmail seems to ignore the case.

LL

---

From: Steve Hanna <[email-masked]>
Date: Thu, 26 Sep 2002 13:11:11 -0400

Marc Jadoul wrote:
> Sometimes it is better to break things! Having 2 users with
> the same email address except cases is really a stupid thing
> to do, and you won't break that much by changing that! Seems
> more like fixing things to me.
>
> Does it exist 1 real world example for having as requirement
> 'cases sensitive email addresses'?

But Ned Freed (one of the authors of the MIME spec) wrote:
> This requirement is well understood by those of us who work
> on email software. Any package that fails to support it gets
> in trouble sooner or later. Indeed, software that preserves
> case but isn't capable of supporting case sensitivity for
> domains it has administrative control over can be problematic.
> I've seen software sales won or lost over this issue.

So apparently there are real customers who care about this
issue, real software that implements case-sensitive matching
for local-part, and long-standing standards that say SMTP
servers must treat local-part as case-sensitive. I'm sure
this question was considered carefully when RFC 2821 and
RFC 2822 were developed. A decision was made to keep handling
local-part as case-sensitive.

The conclusion seems clear to me. We must change the successor
to RFC 3280 to say that local-part should be matched using
case-sensitive matching.

-Steve