はてなブックマーク

メールサーバーを立ち上げて運用するのはとても面倒です。ユーザーをサーバー上に作成するのも面倒でしょう。そこで使ってみたいのがDockerイメージで配布されているソフトウェアです。これを使えばメールサーバーが一瞬で立ち上げられます。 今回は本番運用可能なもの、開発用など様々なメールサーバーを紹介します。 docker-mailserver/docker-mailserver SMTPやIMAP、LDAP、アンチウィルス/スパムが一つになったメールサーバーが立ち上げられます。本番運用も見据えたDockerコンテナとなっています。DKIMやDMARCも含まれています。 docker-mailserver/docker-mailserver: Production-ready fullstack but simple mail server (SMTP, IMAP, LDAP, Antispam,

Customers Mail Cloudを使ってメール配信を行う際に必要なのがドメインに対するSPFレコードとDKIMレコードの設定です。メール配信元が信頼できるのを証明することで、迷惑メールとして処理されるのを防止できます。 各ドメイン管理サービスによって設定方法が異なります。今回はAWS Route53での設定方法を紹介します。 Route53でホストゾーンを作成する まず最初にRoute53にログインしてホストゾーンを作成します。これはドメイン単位で作成しますので、ドメイン名を入力します。 ホストゾーンの作成 作成すると、ネームサーバのアドレスが生成されます。このネームサーバのアドレスを任意のドメイン管理サービスのネームサーバ設定に適用します。そうすることで、DNS設定はRoute53で行えるようになります。 ネームサーバのアドレス DKIMドメイン設定 Customers Mail

Firebase Hostingを使えば静的なWebサイトを手軽にホスティングできます。しかし、Webサイトは静的な情報だけでは物足りないものです。たとえばお問い合わせフォームなど、動的な要素も組み込みたくなるでしょう。 Firebase HostingにはCloud Functions for Firebaseと連携して動的コンテンツやAPIを追加する機能があります。今回はその機能を使ってお問い合わせフォームを作ってみました。 Hosting側の設定 firebase CLIでプロジェクトを作成したら、firebase.jsonを開きます。そして、次のようにリライト条件を追加します。 "rewrites": [ { "source": "/functions/**", "function":"contact" } ] Hosting側にて、HTMLでお問い合わせフォームを作ります。今回は

「SMTPによるメール送信の仕組み」ではメールを送信するためのプロトコル（SMTP）の話をしましたが、 そこではDATAコマンドで送信するメールの形式については言及しませんでした。 今回は、メールの形式について説明します。 ７ビット 基本的にSMTPは７ビットのプロトコルです。 それでやり取りされるメールも７ビットのコードを使用します。 この７ビットであることが、様々な制約を生みメールの形式を複雑にしています。 ヘッダと本文 メールは大きくヘッダと本文に分けられます。 ヘッダは、ヘッダ名と値の対になっておりコロン:で区切られます。 Date: Fri, 29 Sep 2017 14:32:15 +0900 SMTPの１行は1000オクテット（≒バイト）なので、無制限に長くすることはできません。 そのために複数行で表現できるようになっています。 実際には1000オクテットまで伸ばさずに78オ

メールを送信するために使用するプロトコル（SMTP）について説明します。 SMTPはRFC 821で定義され、何回か改定して現在はRFC 5321になっています。 改定により細かなところは変わっていますが基本は同じです。 互換性を保持していてRFC 821の仕様で送信しても現在のメールサーバは受け付けることになっています。 メールサーバに接続する メール送信するときに、まず初めに行うことはメールサーバに接続することです。 はい、そこズッコケない！！ メール送信するクライアント（メーラー）の送信設定には、SMTPサーバのホスト名、ポート番号、認証、暗号化などの項目があります。 各SMTPサーバもこれらの情報を公開しており、メーラーはその設定を行えば送信できます。 さて、受け付けたメールサーバはそのメールをどうするのでしょうか？ メーラーは世界中のどのメールアドレスに送信する場合でも、設定した

DMARCとは 日々メールを受信している私たちは、「誰が」送信したメールなのかを知るほぼ唯一の手段として、 メールの「差出人アドレス（From)」を見ています。 しかし、電子メールは仕組み上、From を自由に設定することができます。 この仕組みと人の習慣を悪用し、From を企業やブランドのドメインになりすまして人々を信用させて、 フィッシング行為が行われるケースがあります。 このようなケースでは、直接の被害者はもちろん、 なりすまされた企業やブランドにも大きな被害が発生することが考えられます。 電子メールを取り扱う企業や組織の間では、こうしたなりすましの問題に対して、 送信ドメイン認証の導入を進めてきました。 送信ドメイン認証とは、DNSを利用して、ドメイン所有者が許可した者が送信したメールであるかを検証する技術です。 現在、SPF(Sender Policy Framework) と

送信したメールがエラーになると、それを知らせるメールが戻ってきます。 今回は、そのメールがどこに戻ってくるのかについてお話しします。 はい、あなた。『そんなの送信した人の所に決まってるよ。』と思いましたね。 その通り。送信した人の所です。 でも、その送信した人って誰？ 普通の郵便、紙のヤツね、あれを思い出すと宛先の他に差出人の住所・氏名も書きますよね。 それで、宛先が間違っているとその差出人の所に「宛先不明」みたいなゴム印を押されて戻ってきます。 メールも同様です。 メールを送信するときには宛先のメールアドレスの他に差出人のメールアドレスも指定します。 この差出人のメールアドレスにエラーメールが戻ってきます。 このメールを送信するときに指定するメールアドレスを宛先はエンベロープ To、差出人はエンベロープ From と言います。 エンベロープ From は、メールを送信するプロトコル SM