思いやりのある友人が最近、私が送信する電子メール( Neomutt ; Mutt、Gnus、またはPineの可能性があります)が彼のデバイスで面白そうだと知らせてくれました。
どうやらGoogleは標準を適切にフォーマットすることに多くの努力を費やしていないようです RFC 2822 テキストメール。
Gmail 月間アクティブユーザー数が10億人以上 であることを考えると、問題のせいにするのは無駄のようです。
メールを「正常」に見せるために自分でできることはありますか?私は format = flowed を使用して満足しています やや非公式 Emacsでサポートされています;しかしどうやら Gmailはそれをサポートしていません 。
頭に浮かぶもう1つの解決策は、プレーンテキストの電子メールをある種のMarkdownパーサーに通して、HTMLに変換し、これを送信電子メールの代替形式として添付することです。私はこれを実際には考えていませんが、Markdownがすでにサポートしているのでうまくいくようです
引用テキスト
および二重引用符で囲まれたテキスト
標準を使用して>
、>>
プレフィックス。おそらく、結果は「普通の」人々がグラフィカルな電子メールクライアントを使用して送信する電子メールよりもさらに良く見えるでしょう。
人々はこれをしますか?彼らはこれを行うことができますか(例えば、Mutt/Neomuttで)? 「標準」ソリューションとは何ですか?
pythonのdocutilsを使用して「markdown」を「HTML」に変換する「plainMail2HTML」を確認してください。これまでのところ、私は結果が有望であることがわかりました。詳細については、githubリポジトリをご覧ください。
バイバイ
私の質問では、同じトピックに関する以前の議論、たとえば別のULの質問、 muttを使用してマークダウンで書かれた電子メールを送信する を見逃しました。その質問は、共有コンピューターまたはMuttが使用する「sendmail」を変更できないその他の状況でこれを行う方法に関するもののようですが、私のユースケースに適合するソリューションにリンクしています。
解決策は2009年のdgl.cxからです Markdownを使用したmutt付きのHTMLメール これは、作成画面のキーストロークをバインドして、偽の「エディター」を介して特別な名前のHTML添付ファイルを作成します。次に、偽のsendmailは、この特別な名前のHTML添付ファイルを検出すると、マルチパート/代替構造を作成し、それを実際のsendmailに渡します。
上記のULディスカッションのコメントの1つは、「NoSubstance」ブログ投稿 muttの秘密のソース にリンクしています。これも非常に役立ちました。
どちらのアプローチも、より原始的な治療で発生するいくつかの問題を解決します。
適切なマルチパート/代替添付ファイルを作成する方法。 Muttを使用している人が元のソースを表示し、Gmailを使用している人がHTMLを表示できるように、text/plainとtext/htmlの両方を含むmultipart/alternativeを送信します。マークダウンは、ソースも人間が読める形式であるという点で、これに理想的です。ただし、どうやら マルチパート/代替構造の送信メール はNeoMuttでのサポートがまだ始まったばかりです。 dgl.cxの投稿は、偽のsendmailにマルチパート/代替構造を作成させることでこの問題を解決します。 No Substanceの投稿には、Markdownの解析を追加で行う偽のsendmailがあります。 NeoMuttのマルチパート/代替の新しいサポートにより、偽のsendmailが不要になるさらに優れたソリューションが登場する可能性があります。
プレビューを許可する方法。代替のSendmailに切り替えるだけで十分簡単なHTMLバージョンを添付する場合は、メッセージが送信される前にこれがどのように表示されるかを確認するとよいでしょう。 No Substanceの投稿で指摘されているように、これは、Muttがドラフトメッセージを格納しているファイルを監視することで実行できます。このファイルの場所は、「延期された」変数で構成されています。 dgl.cxソリューションの場合、HTMLバージョンはすでに添付ファイルとして表示されており、手動で開くことができるため、これは実際には必要ありません。
私はまだどちらの解決策も試していませんが、より単純に見えるので、dgl.cxからの解決策に傾いています。