前回に引き続き、メールのメッセージ構造について書きたいと思います。参考リンク大まかな構造メールメッセージの基本的な形式はRFC5322で規定され、大まかに分けるとヘッダ部とボディ部に分かれます。(今回添付ファイルが付いたケースは別とします。)ヘッダ部ヘッダ部はさらに下記のような要素に分かれます。メールアドレス読んで字のごとくです。From/Sender/Reply-ToFromはメッセージ作成者、Senderは送信者です。同一の場合、Senderは不必要です。To/Cc/Bccそのままのいみです。厳密にいうとToと送信先が違うケースもありますが、ここでは省略します。Dateメッセージの送信時刻です。Message-Id/In-Reply-To/ReferencesMessage-Idはメッセージをユニークに識別する記号です。In-Reply-Toはメッセージに返信する際に付加されます。Referencesも近い概念ですが、直接の返信元だけでなく、返信を繰り返すたびに追加されていきます。Subject件名です。ボディ部こちらはメールの本文の情報になります。ボディ部も通常はASCII文字だけで構成されます。Unicode以前はASCII文字だけで構成されているISO-2022-JPというエンコーディングがあります。日本語だけで送る場合は今でもISO-2022-JPで送ることがい一般的です。MIMEASCII文字だけの場合は件名に日本語や送信者を記述できませんでしたし、バイナリデータを送ることもできませんでした。MIME規格が生まれたことで件名に日本語とバイナリデータを添付させることができるようになりました。ヘッダ中の非ASCII文字MIMEではASCII文字にエンコードすることでヘッダ中に非ASCII文字を入れることができます。=?UTF-8?B?5pel5・・などの文字はこのエンコーディングされた文字列を表しています。処理自体は複雑なため、技術者中瀬です。(私もこれで苦労したことが結構あります。)Content-Transfer-Encoding次はボディ部の変換になります。ISO-2022-JP以外はいずれも8bitデータであったり、テキストデータでないこともあるため、これらを変換するためにBase64とQuoted-Printableという規格が使われます。(ここではBase64のみに触れます。)Base64バイナリデータをテキストに変換します。Content-Transfer-Encoding:base64と指定します。Content-Typetype/subjectの形式でボディ部のデータの種類を表します。JPEG画像など8bitデータの扱いSMTPは基本的に7bitのデータしか扱えませんが、拡張で8bitデータを扱うこともできます。文字化け対策メールが文字化けをする場合、下記のようなことが原因であることが多いです。charasetが正しくないテキストがsjisなのにContent-TypeにISO-2022-JPが含まれているなど。charasetに含まれない文字を使用している例えば半角カナ、〇囲み、カッコつき漢字など・MIMEエンコーディング=?UTF-8?B?5pel5・・の部分がダブルクオートでくくられていたりするとエンコーディングが正常に行われません。コメントをキャンセルメールアドレスが公開されることはありません。share実はvagrantを使って仮想環境を一時的ではありますが、webから見ることができます。https://atlas.hashicorp.com/account/newにてアカウント登録。悪意のあるサイトの特定上の場所をクリックさせ、誤操作をさせ、意図しない機能を実行させられる可能性があります。...docker-composeに関してdockerで環境構築する場合は基本的に下記のような流れをとると思います。...メールの文字化け対策メールの文字コードに関して、色々ごまかしながらやってましたが真面目に取り組む必要があり、ここでメモ。