Cons: May not work with some servers, mail filters (Spam, Anti-virus, ... scanners). Can lead to unclear consequences, e.g. truncation of the line when the line exceeds some internal software limit, message rejection due to RFC noncompliance, message being silently dropped (for the same reason), possibly breaking with some implementation of dkim-checking filter. If/when Kostya implements encryption/signing, that may break too (or give plenty of headache).
Option 1: No additional hard line breaks at all
This option is basically what I discussed last. If a user composed a new email never insert additional hard line breaks into the email body but only keep the line breaks that were introduced by the composer by purpose. This basically means "one paragraph per line". This solution is cheap, simple and works with any charset and any Content-Transfer-Encoding. However, it is not compliant to any RFC which request that no line of an email body must exceed 76 characters.
Pros: simple, cheap solution, "just works"
Cons: incompliant to RFCs
Option 2: The quoted-printable-solutionI personally hate quoted-printable. (It's a burp of the 7-bit era servers.)
Prior to format=flowed there has been already a solution to allow the client to re-flow the content as specified by RFC 2045, sec. 6.7 The idea is to indicate "soft" line beaks by a preceding =. This kind of line breaks are no real line breaks that should be considered as a part of the content but line breaks that are only inserted to follow the 76 characters per line limitation. This approach is widely supported and chosen by all major desktop email clients.
Pros: Totally compliant to any RFC, widely supported
Cons: Blow up of data volume because only octets with decimal values of 33 through 60 and 62 through 126 are represented literally, everything else is escaped by = followed by hexadecimal digests
I am totally with you. Under no circumstance option 1 should be implemented. I only listed that option for the sake of completeness and to get this thread organized by making unambiguously clear what "option 1" is about.QuoteOption 1: No additional hard line breaks at allCons: May not work with some servers, mail filters, [...] And, the RFCs, if not adhered to, will stop being the common denominator (aka standard) for all participants, which will lead to a chaos.
[...]
Yes, that is a true point. However, this is the only widely implemented solution how to get soft line breaks. From a developer's point of view the "modern" approach (see option 3) is much more desirable. Clearly, we have some sort of chicken-egg problem here. If you support the legacy approach (option 2) then there is no need for other email clients to adopt the new approach (option 3). If you only offer the modern approach this increases the pressure of other mail clients to follow the path, however you loose compatibility in the mean time. Unfortunately, none of the big players (MS Outlook, OS X Mail, Gmail web client, etc.) do support option 3, yet.QuoteOption 2: The quoted-printable-solutionI personally hate quoted-printable. (It's a burp of the 7-bit era servers.) It complicates "grep" on the raw messages, reading raw messages. I suspect it can also interfere with message signing (if/when implemented).
[...]
I do not get what you want to tell me here. Let me recapitulate: Both option 2 and 3 offer a solution how to mark certain line breaks as "soft". These are line breaks that are artificially inserted into the email body in order to be compliant to the 76 character limit but are not meant as an actual part of the message and the email viewer is allowed to re-flow the text. This is the benefit of it. Option 3 is the modern variant, plays nicely with 8-bit encoding and is already optionally supported by AquaMail. (See Settings -> e-mail, advanced -> flow text). The drawback of option 3 is that it is not widely supported. Option 2 also supports a re-flow mechanism, hence it offers the same benefit from the user's perspective, but at the expense of using the quoted-printable encoding.QuoteOption 3: The format=flowed-solutionI am not sure how this solution is much different (in the outcomes) from the existing situation. But I think the mail client should start
[...]
Current situation | Improvement | |
Checkbox "flow text" enabled | 8-bit encoding with format=flowed | 8-bit encoding with format=flowed |
Checkbox "flow text" disabled | 8-bit encoding, just omits the format option and forcefully inserts hard breaks into the e-mail body :( | quoted-printable, insert "soft line breaks" acc. to RFC 2045, sec. 6.7, (5) :) |
quoted-printable, insert "soft line breaks" acc. to RFC 2045, sec. 6.7, (5)
That was the key information that was missing for me in your previous description.QuoteI do not get what you want to tell me here. <...>QuoteOption 3: The format=flowed-solutionI am not sure how this solution is much different (in the outcomes) from the existing situation. But I think the mail client should start
[...]
Option 3 is the modern variant, plays nicely with 8-bit encoding and is already optionally supported by AquaMail.
Now, back to what I am talking about and I am really loosing my patience, because I feel as if people try to misunderstand me by purpose.
It sounds like Kostya has already understood your suggestion.
Current situation Improvement Checkbox "flow text" enabled 8-bit encoding with format=flowed 8-bit encoding with format=flowed Checkbox "flow text" disabled 8-bit encoding, just omits the format option and forcefully inserts hard breaks into the e-mail body :( quoted-printable, insert "soft line breaks" acc. to RFC 2045, sec. 6.7, (5) :)
QuoteBut let me just mention that the first row of this table doesn't quite make sense to me: "Current Situation" and "Improvement" contain the same text (How is that an "improvement"?). I am guessing, you are not suggesting any improvement in the first row, just showing what is happening (no changes) in case when that option ("flow text") is enabled. Right?I believe the suggestion was to do quoted-printable with "soft" line breaks *only if* "flowed text" is off (otherwise there'd have to be a whole new setting, ouch).
HTML messages are now sent quoted-printable (better compat) always.
Plain text messages are now sent quoted-printable if app settings -> mail, other -> flowed text is off.