Cool. I have taken the liberty of reporting your very succinct explanation as an Apple "radar" bug report. Here's what I submitted: Problem report/title: URLs pasted into email are broken in all other mail clients Product: Mac OS X Build number: 10.4.9 Classification: Usability Is it reproducable: Always PROBLEM DETAILS -- Text field Summary: Email sent from Mac OS Mail and read by other mail clients appears to have extra spaces inserted throughout the message, including spaces that break some URLs into two or more pieces, rendering them invalid and unclickable in other mail clients. Apple's crime is that it has adopted a relatively new email standard which has not yet been implemented in any other common mail clients like Mozilla Mail, Thunderbird, or Outlook. That would be okay if Apple had made the feature optional, but there doesn't seem to be a way to turn it off. And, worse, the implementation of the new feature is wrong. Apple shouldn't be segmenting URLs. The new feature is the DelSp parameter that is described in RFC-3676. It is used to implement a new way of inserting soft breaks into Text/Plain email that is meant to be flowed (Format=Flowed), the default for Mac OS plain text email when any lines in the message exceed 72 characters. Soft breaks are marked by ending a line with a space, followed by a line break. The message header specifies "DelSp=yes", which instructs the receiving mailer to logically delete the ending space and the line break. If a URL was broken apart in this way by the sending mailer, the receiving mailer will reconstruct it by removing the intervening space and the line break. Unless, of course, the receiving mailer doesn't recognize the DelSp parameter, in which case URLs will be split by intervening space and won't be valid, clickable links. I said that Apple's implementation is wrong or at least poorly done because the RFC states the following: "Regardless of which technique is used, a generating agent SHOULD NOT insert a space in an unnatural location, such as into a word (a sequence of printable characters, not containing spaces, in a language/coded character set in which spaces are common). If faced with such a word which exceeds 78 characters (but less than 998 characters, the [SMTP] limit on line length), the agent SHOULD send the word as is and exceed the 78-character limit on line length." While it's true that the language says SHOULD and not MUST, breaking URLs is really poor form. Apple should fix this problem. Steps to reproduce: 1. Create a new email in Apple Mail 2. Paste a URL into the email that's longer than a single line 3. View the email in any other mail client than Apple Mail and notice that the second line of the URL is broken and unclickable Expected results: Apple Mail should not break URLs over two or more lines by inserting a space at the end of each line, therefore making the URLs clickable in other email programs. Actual results: Apple Mail breaks the URLs over two or more lines by inserting a space at the end of each line, rendering the URLs unclickable in other email programs. Regression: The problem occurs 100% of the time. Notes: Although Apple Mail is supposedly RFC compliant with its DelSp parameter applied to URLs, there are two problems: 1. No other mail clients support the DelSp parameter, making Apple's RFC compliance impractical 2. Apple is not actually RFC compliant because (as detailed above) the RFC says a generating agent should not insert characters in a single "word" in an email. --END-- According to this blog post: http://www.symphonious.net/2005/07/06/how-to-report-bugs-to-apple/ Apple ranks bugs based on the number of people who report duplicates, so perhaps we could start a campaign to encourage people to submit the bug above? (NB, for reference, my bug submission is number 5116436. Status of it can be viewed at https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb.woa/5/wo/DxScbmWZG1AmB2iwufHetM/4.21 )

Posted by Dan Warne on April 06, 2007 at 12:31 AM EDT #

RFC 3986 allows whitespace within a URI when delimiting it in context:

In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may have to be added to break a long URI across lines. The whitespace should be ignored when the URI is extracted.

Posted by Geoffrey Sneddon on May 31, 2007 at 03:03 PM EDT #