メールはプレーンテキストで読み書きすることを好みます。私の電子メールは80文字の固定幅フォントウィンドウで表示および作成され、適切に引用符で囲まれ（「>」）、ASCIIでマークアップされたテキストメッセージが大好きです。昔のように…
しかし、私は世界が進んでおり、多くの人々がテキストフローを必要とする小さな画面または大きな画面でメールを読み、比例フォントを好むことを認めています。78文字以降のハード改行を含む従来のプレーンテキストメールは、それらに対してうまく機能しません。改行が奇妙な場所に表示されるか、ハード改行にもかかわらずテキストが（ひどく）リフローされます。
私の質問：私のような平文ユーザーの経験を損なうことなく、平文のメールをどのようにフォーマットすれば幸せになりますか？
古いクライアントの古典的な行ごとのサブ78文字の外観を維持しながら、プレーンテキストの段落をリフロー可能としてマークできる「フォーマットフロー」（RFC 3676）について知っています。残念ながら、多くのメールクライアント（多くのWebメーラーを含む）から恩恵を受ける多くのメールクライアントではサポートされていません。
多くの電子メールクライアントは、フローされた段落として表示されることを意図した非常に長い行（改行なし）を生成します。それは今、広く受け入れられている標準ですか？私は3つの問題を見ることができます：
RFC 5322では、行の長さが998文字に制限されています。それより長い段落とは何ですか？
「>」で引用されたテキストはまったくリフローできますか？
非常に長い行をいつどのようにリフローするかを知らない古いクライアントを壊します。
プレーンテキストの電子メールをリフロー可能としてマークする他の標準はありますか？
生成するものは非常に柔軟であることに注意してください。私のメールクライアントは、最初から非常に柔軟に構成でき、必要な場所でハッキングできます（EmacsでGNUSを使用しています）。
また、この質問はHTML形式の電子メールに関するものではないことに注意してください。私はそれらを認識しており、読むことができ、必要に応じて生成することもできます。しかし、この質問はプレーンテキストのメールに関するものです。
最後に、どんな形式の電子メールを受信することは私にとって問題ではありません。GNUSは、すべてのプレーンテキスト形式（およびHTML形式の電子メール）を十分に表示できます。