Direct address shouldn't be case-sensitive

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Register Johndoe@direct.project.com
2. Send direct messages from johndoe@direct.project.com
3. Result emails are never received unless the direct messages come from 
Johndoe@direct.project.com

What is the expected output? What do you see instead?
Direct address is email address which is case-insensitive

Original issue reported on code.google.com by ottepor...@gmail.com on 16 Nov 2012 at 2:57

[GoogleCodeExporter]

This seems to be a known issue with Apache James v3.0 beta: 
https://issues.apache.org/jira/browse/JAMES-1369

A developer posted in the issue that a change to the default case-sensitivity 
has been pushed and will be in the next release. If you are using Apache James 
v2.*, I think just adding <ignoreCase>true</ignoreCase> inside the 
<userrepository/> element might fix things (just a guess).

Original comment by michal.kotelba@esacinc.com on 26 Nov 2012 at 9:57

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Upon looking further -- we believe this is not a defect. According to RFC 2821 
-- the non-domain portion (the part before the @ sign) actually IS 
case-sensitive. See below: 

"The local-part of a mailbox MUST BE treated as case sensitive. Therefore, SMTP 
implementations MUST take care to preserve the case of mailbox local-parts. 
Mailbox domains are not case sensitive. In particular, for some hosts the user 
"smith" is different from the user "Smith". However, exploiting the case 
sensitivity of mailbox local-parts impedes interoperability and is discouraged."

In the real-world -- mail servers typically work where they follow a few best 
practices: 

1) All emails normally are created with all lower case (avoids this issue 
entirely). 

2) If someone sends you an email with a mixed case name like "JohnDoe" you MUST 
preserve it (and keep it separate from "johndoe". 

3) Treat inbound mail to someone on your server as case-insensitive unless you 
have to (e.g. unless your mail server has two users that only differ by case, 
then ignore case when receiving messages). 

So unless the Direct spec altered the underlying rules in the email RFC -- I 
think this isn't a bug according to spec (which we follow as our primary guide 
as this is primarily a spec conformance tool). 

If the original submitter is out there, fire me an email 
(edward.oconnor@nitorgroup.com) -- I'd like to get your two cents. But my view 
is that the issue isn't a significant impediment (just send mail from the exact 
same address you registered) nor are we counter to the letter of the spec. But 
I also admit -- I never actually knew this (I thought the whole email addie was 
meant to be case-insensitive -- but it is just the domain portion by rule). 

- Edward

Original comment by edward.o...@nitorgroup.com on 29 Nov 2012 at 8:57

• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Hi Edward,
Until I started this project, I had no idea email addresses had case-sensitive 
parts. IMO this was poor design....

While you are correct that rfc822 email addresses are case-SENSITIVE for the 
local-part, the submitter is correct that **DIRECT** email addresses are and 
MUST BE case-INSENSITIVE. This is because:
A. The emailAddress (http://tools.ietf.org/html/rfc5280#section-4.1.2.6) legacy 
attribute is case-insensitive. The subjectAltName is case-sensitive, however.
B. DNS CERT records are stored in a case-insensitive manner.
C. ldap queries are case-insensitive (I think, at least by default).

Those are my thoughts... I'm interested in hearing your response. Thanks.

Original comment by dca...@meditech.com on 3 Dec 2012 at 12:46

[GoogleCodeExporter]

(This is just my advice as a community member, not authoritative in any way. I 
believe key Direct contributors and ONC are looking at this (all items that 
fall out of MU2 tool feedback get looked at hard) and may have official 
guidance that differs.)

A few points on this one: 

I'm currently viewing this as interesting spec discussion as it applies to this 
test tool -- not something that a user needs changed in this particular tool. 
Here's why: 

1) It isn't a blocker. Note the underlying functionality in the tool we're 
talking about is just where the tool asks for the sender's direct addie and 
non-direct addie so it can know who is sending it messages (and where to send 
test results). Case-sensitivity of the address isn't something we're testing -- 
it is just something that came up due to the communication portion of the tool. 
In other words, a user can successfully utilize the test tool by simply 
entering their email address correctly in our interface (correctly = matching 
case). 

2) Our test tool utilizes a version of the Direct Java RI to receive emails -- 
so if the RI decides this is a bug, our tool will eventually migrate to the new 
RI and the issue will go away (though I'm not convinced it is a bug -- it makes 
sense to follow the Direct reference's lead). I need to check into this and 
make sure it's true -- but I assume we're inheriting this behavior from our 
underlying email server, as opposed to our interface code. <-- To-do item. 

-------
So the important aspect of what we're talking about isn't an issue in this 
tool, it is basically a specification discussion coincidentally generated by 
using the tool.  In terms of the spec discussion -- that really isn't my area 
-- would recommend you have a transparent one with the Direct community overall 
(though I know there is a giant email thread going around about it already - it 
isn't totally open yet). 

Here's why I recommend that:

a) This has uncovered some murky spec. An underlying spec (2821) quotes very 
clearly that the subject portion MUST be case sensitive. Specs referencing 2821 
don't clearly constrain it (though as you pointed out, some areas like 5280 
might implicitly constrain it). 

b) So my advice -- don't dance around constraining it by making an implicit 
constraint argument (that's how I read the latest response) -- just explicitly 
constrain the spec (in the Direct spec). Implicit spec constraints are 
confusing spec constraints that end up only being understood by the people that 
happened to be in the thick of threads like these. If you see a need for a 
constraint to 2821 -- just make an explicit one (make the spec SPECIFIC). Make 
things clear and easy for implementers -- especially implementers who get the 
idea to use an existing email server in their enterprise which might REALLY 
care about case-sensitivity. Even if your implicit argument grows (e.g. if you 
find spec references to support "B" and "C"
in your case) - then I recommend putting that explanation into the Direct spec 
(don't make people figure out something like this -- peel the onion for them 
and expose the conclusion openly/clearly). 

Note I see both arguments for and arguments against constraining this. 2821 
left in that caveat for case-insensitivity to support legacy email server 
interoperability -- they did this for a good reason. Due to how Direct merges 
email/certs, I think a constrain might make sense, but it also might hose 
anyone using an email server who respects that legacy constraint. 

Original comment by edward.o...@nitorgroup.com on 3 Dec 2012 at 4:46

[GoogleCodeExporter]

Thanks for the responses, I think I have the information I need now. I'm glad 
to know this is being looked at further by the DIRECT community, and will be 
interested to see how it turns out.

Original comment by dca...@meditech.com on 3 Dec 2012 at 5:40

[GoogleCodeExporter]

Identified as a spec question and directed to ONC for processing. Issue being 
closed for now as a wontFix. 

Original comment by edward.o...@nitorgroup.com on 10 Dec 2012 at 6:54

• Changed state: WontFix