[PATCH] encode mail address when passing via KApplication::invokeMailer

[Ingo Klöcker]

On Saturday 08 January 2005 16:25, Oswald Buddenhagen wrote:
> On Sat, Jan 08, 2005 at 04:02:43PM +0100, Ingo Klöcker 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 
inserted literally into an HTML document (why would anyone do this?) or 
whether they refer to mailto URLs as href parameters. What I definitely 
know is that validator.w3.org complains about any '&' which are not 
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=s, 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 
irrelevant that I didn't test with multiple to/cc/bcc). I just changed 
the code of invokeMailer( to, cc, bcc, ... ), i.e. the code which 
creates a new mailto URL from the given to, cc and bcc. According to 
the above mentioned RFC the value after to=, cc= or bcc= has to be the 
value of a RFC 822 message header encoded as URL. In particular, 
multiple addresses are allowed per to=, cc= or bcc=.

> the encoding is strange/bust - konq shows the utf8 as "source" 
> (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 
URL is indeed wrong. A correct URL for the email address
  Jörg Test <joerg.test at test.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? 
IMO invokeMailer can't expect to, cc and bcc to be RFC 2047 encoded 
email header values. Thus invokeMailer has to do the RFC 2047 encoding 
and that's what it does now in the special case for KMail. Adding a RFC 
2047 codec to KCodecs would be the right solution, but moving the codec 
we have in kdepim is currently not possible. The downside is that we 
have to forget about correct handling of non-ASCII chars in email 
addresses (unless KMail is used). If all non-ASCII chars can be encoded 
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" 
<joerg.test at test.test>. And that's what my patch does and what 
QStringList( ',', x ) does not.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050108/4a694bbe/attachment.sig>