Version: (using KDE KDE 3.3.2) Installed from: SuSE RPMs OS: Linux One of my identities contains an email address with an uppercase 'R' somewhere in the domain part. When I send emails choosing this identity the 'R' finds its way to the From: header. But when I set the default to this identity the domain part is converted to lower case. BTW, you have to view the source of the messages to discover that the 'R' survives in the first case. In the normal message view KMail converts every domain part to lowercase. KMail shouldn't silently(sic!) perform such conversions overriding user settings.
Domain names are case-insensitive. All URLs and all domain names in mailto: URIs, when processed by KDE, are converted to lowercase, which is their canonical form.
> Domain names are case-insensitive. You're mixing up representation with interpretation. The representation "example.com" is definitely not equivalent to the representation "Example.com". The interpretation (by resolving these representation to ip addresses using DNS) will be equal. But resolving From:(!) addresses is not KMail's job. "example.com" and "Example.com" are semantically identic but not syntactically. That's the point ... My problem: mail@ThiagoMacieira.invalid is pretty readable. mail@thiagomacieira.invalid hardly: where ends your forename where starts your surname? > All URLs and all domain names in mailto: URIs, when processed by KDE, are converted to lowercase, I'm not talking about mailto: URIs but usergiven email addresses of KMail emailidentities. The uppercase 'R' will be preserved if and only if the corresponding identity is not the default. That's at least an inconsistency but on no account an invalid bug report. > which is their canonical form. Not in context of Internet Message Format. According to RFC 2822 and 2234: from = "From:" mailbox-list CRLF mailbox-list = (mailbox *("," mailbox)) / obs-mbox-list mailbox = name-addr / addr-spec addr-spec = local-part "@" domain domain = dot-atom / domain-literal / obs-domain dot-atom = [CFWS] dot-atom-text [CFWS] dot-atom-text = 1*atext *("." 1*atext) atext = ALPHA / DIGIT / ; Any character except controls, "!" / "#" / ; SP, and specials. "$" / "%" / ; Used for atoms "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~" ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
I'm sorry if I misunderstood you. Can you provide an example of From: that KMail added that looks wrong to you, and how it should look like?
I can confirm that: 1) in one of the two cases, as the reporter indicates, the email address is case-folded to lowercase. Not so when the identity selected isn't the default -- for the *same* address. 2) in both cases, the email address is SHOWN in KMail in lowercase. Jan: the rationale: email addresses can contain characters outside the ASCII range in the domain name part. Part of those Internationalised Domain Names (IDNs, for short) specification is that a few transformations are applied to guarantee uniqueness. For instance, the German letter ß is always translated to "ss" (i.e., an email someone@fußball.de is the same as someone@fussball.de). KDE applies those transformations to all domain names to guarantee the uniqueness. So, we have the following two options: 1) treat all domains with one single rule: apply the canonicalisation. 2) treat ASCII-only domains specially. We currently do #1 throughout most of KDE. This is what makes all domain names typed in Konqueror turn lowercase; this is also what made your email address show lowercase to me in KMail. We could implement #2. As it is an unimplemented feature (special treating of ASCII-only domain names) and as it does not at all impact the functionality of the program, it is a wishlist. I will not implement this in the core KDE libraries unless so requested by many people. KMail developers can choose to implement it on their own. Aside from that, KMail has an inconsistent behaviour and that is a bug, albeit minor (= it does not prevent the program from working).
Also to be noted: email addresses with IDNs get properly encoded when sending -- that includes lowercasing.
> (...). > 1) in one of the two cases, as the reporter indicates, the email address is case-folded to lowercase. Not so when the identity selected isn't the default -- for the *same* address. That's IMHO a/the bug. In principle it works (:as non-default identity) I've fiddled about with this: Simply reselecting the default identity in the compose dialogue's dropdown list yields to no(!) case-folding. > 2) in both cases, the email address is SHOWN in KMail in lowercase. That's IOHO a wishlist item. :-) > Jan: the rationale: > email addresses can contain characters outside the ASCII range in the domain name part. Part of those Internationalised Domain Names (IDNs, for short) specification is that a few transformations are applied to guarantee uniqueness. or instance, the German letter ß is always translated to "ss" (i.e., an email someone@fußball.de is the same as someone@fussball.de). > (...). Thank you for explanation. Now I understand the display issue/problem.
KDE 4.3 converts all domain names to lowercase, regardless of the identity.
@Martin: That's even worse. In the UI, the From address is shown exactly as I configured it in the identity. Only when I send such an e-mail, the domain part of the From address is converted to lowercase.
The original report was about the different behavior with different identities. This is no longer the case, therefore it's no longer a "Bug" report. Changing to whish. Also, in comment #4 thiago stated clearly that he will not implement this. Sorry about not having endless resources to implement each and every whish. You're welcome to provide a patch though.
Domains are case-insensitive. Lowercase should be enough for everyone (it's correct, even if it's not most aesthetically pleasing), plus it avoids issues with broken software that doesn't deal with IDNs properly.
@Martin: I am the reporter and I know what I wrote: "KMail shouldn't silently(sic!) perform such conversions overriding user settings." This still holds true and has got even worse today. However, this is not a big problem, just somewhat annoying. @Thiago: Perhaps all e-mail addresses should be normalized before putting them in to the line edit boxes in the UI using the same functions that are applied before sending them?
No, the issue I found back in 2005 is that KMail was inconsistent. Under some conditions, it normalised, under others it didn't. I wouldn't mind having the non-normalised email address in the edit boxes, actually, especially if they're IDN.
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding.
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.
It is still valid for kmail2. If I enter an email address with some uppercase letters in the domain part into the From: field, it will be silently converted to lowercase later without further notice. However, due to decreasing importance of emails, I close this as wontfix.
(In reply to comment #15) > It is still valid for kmail2. If I enter an email address with some > uppercase letters in the domain part into the From: field, it will be > silently converted to lowercase later without further notice. However, due > to decreasing importance of emails, I close this as wontfix. "Decreasing importance of emails"? Are you out of your mind? You can come up with a valid reason to justify the WONTFIX, like "the behaviour is correct", which is what I said 7 years ago. In any case, you did not address the part about inconsistent behaviour.
Feel free to reopen.
That would mean retesting if the inconsistency is still present, which I haven't done. My point is that you should have a valid reason for closing a bug. If you don't have one, just say so, instead of coming up with ridiculous claims.
Comment 7 states that the inconsistency was fixed. I did test it. And it is fixed. Furthermore, Comment 9 states that my wishlist item will not be fixed unless I provide a patch myself. I will not fix it because the importance of email has decreased. I will not defend my decision. Feel free to choose another status for my very own(sic!) report.