On 19 Oct 2012, at 17:45, Randall Gellens <randy@xxxxxxxxxxxxxxxx> wrote:
> At 11:42 AM +0100 10/19/12, Sabahattin Gucukoglu wrote:
>> Warning: this message was generated by Apple Mail.
>
> But not using Format=Flowed.
Precisely.
> On 16 Oct 2012, at 03:46, Randall Gellens <randy@xxxxxxxxxxxxxxxx> wrote:
>>> At 9:12 AM -0400 9/5/12, Michael Richardson {quigon} wrote:
>>>> Maybe I'm also concerned because many in the former "elite" have moved to Apple Mail, and it seems that it is bug
>>>> compatible with Outlook in it's assumption that format=flowed is the default, an act which destroys email quoting, and therefore discussion.
>>>
>>> I just noticed this assertion, which is quite false. Format=flowed protects and preserved quoting. It's the only way to avoid ludicrous and impossible to read quoting (which happens after quoted passages get line-wrapped at odd points). Also, as far as I know, Exchange does not support format=flowed at all. My understanding is that it insists on HTML quoting, which is entirely different.
>>
>> You're right that this is the virtue of F/F, but that's not what Michael said. Perhaps it was the context of the quoting, but the discussion refers to the fact that both LookOut and Apple Mail have (as you can see, by looking at this message) a nasty habit of *assuming* an F/F semantic by default. In other words, they generate hugely long long long long long long long long long lines that only another equally broken client can interpret correctly, but dynamically reflowing those lines, by applying consistent quoting indicators to the lines of such reflowed lines, and so forth. That, I believe, is a legitimate complaint, because it e
>
> This reflects a misunderstanding of Format=Flowed. Properly generated F=F has lines of no more than 78 characters. One of the primary goals of F=F is good interoperability between clients that support F=F and those that support traditional pure plain text email. What you're describing is a symptom of HTML quoting (or a surprisingly poor F=F implementation):
Yes, absolutely. We do not disagree.
Let's clear up the confusion. I made two mistakes, firstly by calling this "F/F semantics" when what I mean is some sort of long-line-aware reflowing and quoting. We'll have to find a name for it. The other mistake was to call plain text plain text of any description, irrespective of the definition of text/plain.
So we are talking about three formats:
* text/plain, 78 characters wide
* format=flowed, text/plain with soft breaks signalled by trailing whitespace, 78 characters
* text/paragraphs (or whatever), a completely different identity that violates the length limits
Apple Mail and Microsoft use this text/paragraphs. It's not interoperable with text/plain (because it *isn't* text/plain, as you very correctly note) and therefore it gives everyone a really hard time. Unless you've not dealt with plain text files from Windows or OS X, you may be sure that "Plain text" most certainly doesn't conform to RFC 822, either.
We should now all be on the same page, I think. :-)
> When generating Format=Flowed text, lines SHOULD be 78 characters or
> shorter, including any trailing white space and also including any
> space added as part of stuffing (see Section 4.4). As suggested
> values, any paragraph longer than 78 characters in total length could
> be wrapped using lines of 72 or fewer characters. While the specific
> line length used is a matter of aesthetics and preference, longer
> lines are more likely to require rewrapping and to encounter
> difficulties with older mailers. (It has been suggested that 66
> character lines are the most readable.)
>
> The restriction to 78 or fewer characters between CRLFs on the wire
> is to conform to [MSG-FMT].
>
>
>> At least Apple has the decency to use quoted-printable encoding to protect the actual transmitted lines,
>
> Again, this shows a fundamental misunderstanding of F=F. Properly generated F=F does not use quoted-printable unless otherwise needed:
Yes. Apple Mail doesn't do this--it uses QP to keep the line lengths valid in transmission only. Some mailers, or gateways, wouldn't do that, but would instead spew out long lines that compliant SMTP servers would helpfully corrupt, tail-drop, chop into pieces, etc (for lack of robustness or to protect themselves).
>> but it means nothing if competent MIME readers reconstitute the corruption at the other end, by reassembling long lines, and then failing to reflow them. And it's worse yet if a news reader without MIME tries to quote the lines, complete with Q-P line terminators. Or if a reply comes from somebody whose editor wraps the lines, but using soft line breaks which are never generated externally, resulting in whole paragraphs being quoted using a single quoting indicator. And so on, and so on, and so on Š
>
> All of these are part of the problem set that F=F was created to fix. Proper F=F plays nice with pure plain text.
My first exposure to large numbers of affected people was on Usenet, when I sent mail from Apple Mail through a gateway. Apparently, newsreaders fall into the categories of having no MIME at all, or having MIME but not reflowing text. In any case, they were unhappy. :-(
>> I filed bug 7989556 (Mail uses quoted-printable indiscriminately) with Apple on 16 May 2010. It was marked as duplicate of 7547565 on 25 May 2010. The system is closed; you can only see your own bug reports. I therefore have no idea what's going on with that. Meantime, I apologise for the inconvenience. No, really. :-(
>
> I haven't looked into Apple's mail's generation of either F=F or plain text or HTML. If it generates F=F with long lines and/or indiscriminate q-p, then those would in my view be bugs that should be fixed. But I don't know if the symptoms described occur with Apple Mail's F=F or some other format. To me, they sound like lack of F=F.
At one point--in Leopard (10.5), I think--they were using F=F. It almost looks like the current behaviour is what's left of the F=F implementation, in that it renders and sends emails that can be flowed, though using text/paragraphs rather than F=F.
Cheers,
Sabahattin