From kde-core-devel Sat Jan 08 16:18:39 2005 From: Ingo =?iso-8859-1?q?Kl=F6cker?= Date: Sat, 08 Jan 2005 16:18:39 +0000 To: kde-core-devel Subject: Re: [PATCH] encode mail address when passing via Message-Id: <200501081718.59558 () erwin ! ingo-kloecker ! de> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110520115605103 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart5224965.PbEhqB5ANi" --nextPart5224965.PbEhqB5ANi Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Saturday 08 January 2005 16:25, Oswald Buddenhagen wrote: > On Sat, Jan 08, 2005 at 04:02:43PM +0100, Ingo Kl=C3=B6cker wrote: > > > i don't care about the details, but if you break %u for mutt, > > > i'll make you a head shorter. ;) > > > > Can you then please test this with Mutt? Attached is a tiny > > HTML-test file. > > the url is bad (should be & not &) RFC 2368 - "The mailto URL scheme" reads: Because the "&" (ampersand) character is reserved in HTML, any mailto URL which contains an ampersand must be spelled differently in HTML than in other contexts. A mailto URL which appears in an HTML document must use "&" instead of "&". Of course it's unclear whether they refer to mailto URLs which are=20 inserted literally into an HTML document (why would anyone do this?) or=20 whether they refer to mailto URLs as href parameters. What I definitely=20 know is that validator.w3.org complains about any '&' which are not=20 encoded as '&' in any href's of your XHTML document. > and doesn't cover all cases by far (multiple to/cc/bcc). See next comment. > the changed composer does not permit multiple to=3Ds, a thing i do > pretty often (not in urls, though, but that's because i don't do much > html). I didn't touch the code which rips mailto: URLs apart (and thus it's=20 irrelevant that I didn't test with multiple to/cc/bcc). I just changed=20 the code of invokeMailer( to, cc, bcc, ... ), i.e. the code which=20 creates a new mailto URL from the given to, cc and bcc. According to=20 the above mentioned RFC the value after to=3D, cc=3D or bcc=3D has to be th= e=20 value of a RFC 822 message header encoded as URL. In particular,=20 multiple addresses are allowed per to=3D, cc=3D or bcc=3D. > the encoding is strange/bust - konq shows the utf8 as "source"=20 > (latin1, i suppose), and the url passed to mutt is utf8, too. maybe > that's just the url. Yeah, I shouldn't have added a non-ASCII char to the example. The mailto=20 URL is indeed wrong. A correct URL for the email address J=F6rg Test is mailto: %3D%3Fiso-8859-15%3Fq%3FJ%3DF6rg%3F%3D%20Test%20%3Cjoerg.test%40test.test%3E The problem now is what does invokeMailer( to, cc, bcc, ... ) expect?=20 IMO invokeMailer can't expect to, cc and bcc to be RFC 2047 encoded=20 email header values. Thus invokeMailer has to do the RFC 2047 encoding=20 and that's what it does now in the special case for KMail. Adding a RFC=20 2047 codec to KCodecs would be the right solution, but moving the codec=20 we have in kdepim is currently not possible. The downside is that we=20 have to forget about correct handling of non-ASCII chars in email=20 addresses (unless KMail is used). If all non-ASCII chars can be encoded=20 in local encoding then it should still work in most cases. But what we can care for is email addresses of the form "Test, Joerg"=20 . And that's what my patch does and what=20 QStringList( ',', x ) does not. Regards, Ingo --nextPart5224965.PbEhqB5ANi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBB4AfzGnR+RTDgudgRAmKuAJ92nbIbFtARNuPGtBElQtnZwdJ8uwCfdweV C/99D8GlGeY0tZ62jrnkfcU= =yzUU -----END PGP SIGNATURE----- --nextPart5224965.PbEhqB5ANi--