#topicpath
** メールサーバ構築のためのメモ [#zff87692]
*** はじめに [#l804f90a]
&amazon(477951391X);
- そのはじめに~
最近、インターネットを検索しても、欲しい情報が一度に手に入らないことが多い。なぜか?そして、私はどうするか?~
ちなみに、私の話は前置きが長い。~
~
- アメリカの話~
アメリカでは、共和党と民主党の人は、互いに話をしなくなっていて、一つの国の中に二つの国民性があるような国になっているようだ。情報流通が激しくなると、自分の知りたくないことについては知らなくていいような社会になっているのかもしれない。~
~
- インターネットの話~
ネットワークの世界でも同様のことが起こっているような気がする。昔は、ソフトウエアを作る人とソフトウエアを使う人の距離が近かった。パソコンを使う人は、かなりの確率でソフトウエアを作る人だった。ところが、ソフトウエアを使うだけの人が増えてくると、コミュニケーションの分断が起こってくるのかもしれない。その結果、昔はインターネットを検索すれば、複雑な設定ファイルに関する情報が比較的容易に得られたが、今はそれが困難になっているように思われる。ソフトウエアを作る人は、グループで開発し、その人たちの間ではコミュニケーションは濃くて密だろう。ところが、一般ユーザーは、とりあえずソフトウエアが動けばいいので、ユーザー目線の情報しか追わない。~
~
メールサーバの構築について情報が少ないと感じるのは、もしかしたら、こうした状況が進展した結果かもしれない。ここでは、メールサーバの構築について、基本的な情報から書いてみる。例によって間違ったことを書いていたらごめんなさい。~
~
*** 基本的な用語 [#ke15dfc5]
- Agent シリーズ~
ソフトウエアの種類について書く。
-- MUA: Mail User Agent~
--- 意味~
ユーザーがメールを書く。書いたメールを、ポチっと、送る操作を行ってメールを送信する。この送る操作を受けて、メールを MTA に手渡すソフトウエアのこと。~
また、メールを受信するときに、ポチっと、受信する操作を行ってメールを受信する。この受信しますという操作を受けて、メールを受け取って表示・保管するソフトウエアのこと。
--- 例~
Thunderbird のようなソフトウエア~
~
-- MDA: Mail Delivery Agent~
--- 意味~
ソフトウエア同士で話をしてメールの転送を行うソフトウエアのこと。近年は、セキュリティの関係で、暗号化したりユーザー認証をしたりしないと送信できないことが増えたので、以前に増して設定が複雑になっていると思われる。~
~
-- MTA: Mail Transfer Agent~
--- 意味~
MUA から受け取ったメールを、相手先に転送(Transfer)するために、配送先を決定するソフトウエアのこと。実際の送信はMDAが行う。しかし、MDA は MTA と一体化していることが多い。一体化したものは MTA と呼ばれるので、MTA には2つ意味があると考えた方が良い。
--- 例~
MTA と MDA をセットにしているものとして。~
sendmail, postfix, exim4, qmail~
~
-- MSA: Message Submission Agent~
--- 意味~
MUA と MTA の間に設けられた概念。あまり意味が無い。いわゆるスパム(迷惑メール)が増えたために、これを抑えることを目的としてOP25B(Outbound Port25 Blocking)と呼ばれる制限が行われるようになった。この制限を越えて、メールを送信するためには、ユーザー認証をして送信する必要がある。それを実現するのが MSA である。後述のTCPのポートは 587番ポートを利用する。また、後述の STARTTLS を利用することが多いようだ。MUA, MTAに組み込まれていると考えられる(本当か?)。~
~
~
- Protocol シリーズ~
通信のし方について書く。
-- SMTP: Simple Mail Transfer Protocol~
--- 意味~
マシン間でメールをやり取りするときの通信規約(Protocol)のこと。メールの送受信のための通信方法を決めている。通信の決まりなので、特定のソフトウエアには対応していない。MTA が SMTP をしゃべることになる。つまり、日本人が日本語をしゃべることになぞらえると、「MTA 語」と言える。~
ちなみに、プロトコルには層(Layer)がある。IP(Internet Protocol)と呼ばれるインターネットの基本的なProtocol の上に TCP(Transmission Control Protocol)があり、TCPの上に SMTP がある。TCP にはポート番号と呼ばれる通信規約ごとの番号(ポート番号)が決まっている。SMTP は TCP の25番ポートを使うと決められている。ところが、近年、旧来通り暗号化していない場合と区別するために、TCP 587 番ポートを使うことがあるので、注意が必要であり、番号も記憶する必要がある。(なお、後述のSMTPSは、我々が設定するのは非推奨らしい。)~
~
-- POP3: Post Office Protocol Version 3~
--- 意味~
メールサーバに蓄積されたメールを MUA が取り出すときの通信規約(Protocol)のこと。TCP の110番ポートを使う。~
このとき、メールサーバに対して、当然、「私は本当に私です」と認証をしなければならないので、認証情報のやり取りの仕組みが備わっている。牧歌的な昔は気にしていなかったが、今はとても重要な課題である。これを解決するために、いくつかの方法がある。APOP(Authenticated POP) はその一つであるが、今はあまり使われていないので述べない。POP3S(POP over SSLとも) は、暗号化した通信経路を確保した上で、POPの通信を行うものである(後述)。~
~
-- IMAP: Internet Message Access Protocol~
--- 意味~
メールサーバ上のメールにアクセスして操作するための通信規約(Protocol)のこと。TCP の143番ポートを使う。~
メールの受け取りという意味では、POP3 と重複する。メールサーバ上のメールを操作できる点でメリットがある。~
--- 例 (サーバ・サーバ側ソフトウエア)~
Gmail, Dovecot
--- 例 (クライアント側ソフトウエア)~
Mew, Eudora, Mutt, Microsoft Outlook~
~
-- SSL: Secure Sockets Layer
--- 意味~
後ほど述べる TLS の前身である。今時はTLSを使うが、旧来の名前の名残で、TLS を SSL ということもあるので注意する。~
~
-- TLS: Transport Layer Security
--- 意味~
プロトコルの一つで、通信相手の認証、暗号化などに対応している。この層(Layer)の上で、ファイル転送等の通信を行うことで安全性を確保している。例えば、ウェブページの送信に使われる HTTP(Hyper Text Transfer Protocol)を TLS の上に載せることで暗号化された HTTPS 通信を行うことができる。(次の表を参照のこと。表は [[Wikipedia>https://ja.wikipedia.org/wiki/Transport_Layer_Security#%E3%82%A2%E3%83%97%E3%83%AA%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E5%B1%A4%E3%83%97%E3%83%AD%E3%83%88%E3%82%B3%E3%83%AB%E3%81%B8%E3%81%AE%E9%81%A9%E7%94%A8]] から。)~
|TLSと組み合わせたプロトコル|	ポート番号|	元のプロトコル|	ポート番号|備考|h
|HTTPS|	443	|HTTP	|80| |
|SMTPS|	465	|SMTP	|25|ユーザーが設定するのは非推奨らしい。 |
|LDAPS|	636	|LDAP	|389| |
|FTPS (data)|	989	|FTP (data)	|20| |
|FTPS (control)|	990	|FTP (control)	|21| |
|IMAPS|	993	|IMAP	|143| |
|POP3S|	995	|POP3	|110| |
--- 通信の暗号化(公開鍵暗号方式 RSA: 発明者3人の頭文字)~
具体的な通信では、まず、暗号化のための条件(TLSのバージョン、乱数)をそろえた後、公開鍵を交換する。公開鍵は、相手に送信するデータを暗号化するために使う。受信した方は、外部に公開していない秘密鍵を保持しており、これを使って復号化する(元のデータに戻す)。秘密鍵でないと元に戻せない。他にも共通鍵方式(AES: Advanced Encryption Standard)とかあるが、ここでは省略する。
--- デジタル署名~
サイトAがデータを送信してきたとき、それが、本当にサイトAから送られてきたものかを確かめるための方法。~
サイトAは、データと共に、そのデータを秘密鍵で暗号化したデータも送ってくる。その暗号化したデータは、サイトA の公開鍵で初めて復号化できる(元に戻せる)。復号化できて、両者が一致すれば、サイトAから送られてきたものだと確かめることができる。~
--- サイトの認証~
TLS では、通信先が、正しく通信先であることを保障しようとする。つまり、例えば、robo.mydns.jp へアクセスしたつもりが、robo.mydns.jp とインターネット上のアドレスである IP アドレスとの「ひもづけ」を、誰かが悪意を持って改竄(かいざん)したために、別のサイトへアクセスしてしまうことを避けたいと考える。そのためには、信頼できる第3者が、このサイトは確かに robo.mydns.jp です、と証明する必要がある。しかも、その証明書(CRT: Certificate)は、偽造できないようになっていなければならない。~
~
そこで、次のようにする。私(robo.mydns.jp管理者)は、証明書発行要求(CSR: Certificate Signing Request)を認証局(CA)に対して行う。具体的には、秘密鍵と公開鍵を作成し、公開鍵を認証局に送る。認証局は、認証局の秘密鍵でデジタル署名し、それを証明書として私に送り返す。私は、robo.mydns.jp に証明書を置いておく。robo.mydns.jp を利用する人は、証明書を拾う。認証局の公開鍵で証明書が正当なものと認められれば、robo.mydns.jp は確かに、robo.mydns.jp であると認められる。なお、認証局としては、本当に私が robo.mydns.jp 運営者であるかを確かめる必要があるが、それはまた、別の問題であるので、ここでは述べない。~
~
-- STARTTLS~
--- 意味~
通信開始時は暗号化されていないが、途中から TLSによる暗号化通信を行うように切り替わる。Gmail などが採用している。~
~
-- SASL: Simple Authentication and Security Layer~
--- 意味~
他の通信規約とは分離して認証を行うための仕組み(フレームワーク)。TLS とセットで使われる。~
一口にSASL といっても、ログイン機構を代替するPLAIN機構、ワンタイムパスワード機構など、いくつかの機構がある。~
~
- メール関連用語~
-- FQDN: Fully Qualified Domain Name~
--- 意味~
ドメイン名(mydns.jp)にホスト名(robo)を加えて、robo.mydns.jp としたときのホスト名のこと。DNS(Domain Name System)で、IPアドレスを調べることができる。~
~
-- MXレコード: Mail eXchange Record~
電子メールを送信する際、そのドメイン宛のメールの配送先を表す。DNS で提供される情報である。~
~

*** POSTFIX によるメールサーバの構築 [#qf7cece0]
- 環境
Debian10(buster) で、so-net (STARTTLS使用、SMTP AUTH認証使用)を経由してメールを送信する。~
~
- MTAの選択~
-- sendmail~
正統派のソフトウエアである。以前から設定が難解と有名で、オライリーの分厚いテキストもあった。今や2分冊である。却下。~
&amazon(4873111765,image);&amazon(4873111803,image);~
-- qmail~
機能ごとに分かれたコマンドを提供し、セキュリティによく対応したと評判であった。私もこれまで使ってきた。~
ところが、メインテナンスされておらず、色々なパッチが提供されて、それで対応しなければならない。その上、最近は利用者が減って、情報が極めて少ないので、残念ながらこれを放棄する。~
-- exim4~
よく調べていないけど、あまり印象が良くない。~
-- postfix~
現在、最も支持を受けているようなので、これを採用する。~
くわしい文章は、[[ここのサイト>http://www.postfix.org/documentation.html]]にある。
~
- 導入
 apt-get install postfix openssl
- 設定
-- 自動的に行われる設定~
--- 秘密鍵
 /etc/ssl/private/ssl-cert-snakeoil.key
--- 公開鍵
 /etc/ssl/certs/ssl-cert-snakeoil.pem
~
-- 導入時に聞かれる設定~
次のものを選択した。
--- メール設定の一般形式: スマートホスト付きインターネット
--- システムメール名: 適切に。
--- SMTP リレーホスト: mail.so-net.ne.jp:587~
~
-- 導入後の設定~
+++ SMTP リレーホストへのログインについて~
[[Debian の解説>https://www.debian.org/doc/manuals/debian-reference/ch06.ja.html]]を参照して次を実行した。
 sudo postconf -e 'smtp_sender_dependent_authentication = yes'
 sudo postconf -e 'smtp_sasl_auth_enable = yes'
 sudo postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
 sudo postconf -e 'smtp_sasl_type = cyrus'
 sudo postconf -e 'smtp_sasl_security_options = noanonymous'
 sudo postconf -e 'smtp_sasl_mechanism_filter = plain'
最後の2行は上記サイトに書いていないが、重要と思われる。main.cf に追加されたことを確かめる。次に
 sudo vim /etc/postfix/sasl_passwd
で、
 mail.so-net.ne.jp:587     username:password
を作成し、
 sudo postmap hash:/etc/postfix/sasl_passwd
を実行する。(※ 上記のDebian の解説では hush になっていて誤り。正しくは hash)。最後に~
 sudo /etc/init.d/postfix restart
で postfix を再起動し、変更を有効にする。~
~
-- デバッグ~
基本的には、メールが届いたかを確認し、また、/var/log/mail.log をチェックする。
+++ telnet で smarthost から送信してみる。(cf. [[telnetからSMTPを使ってメール送信>https://qiita.com/sheepland/items/973198fa80f0213fe5a1]])
 telnet mail.so-net.ne.jp 587
で接続する。
 EHLO localhost
とか
 AUTH PLAIN 認証用文字列
とか
 MAIL FROM:送信元メールアドレス
とか
 RCPT TO:送信先メールアドレス
とか
 DATA
とか
 Subject: hoge
 From: 送信元メールアドレス
 To: 送信先メールアドレス
 
 hello!
 .
とか入力してみる。パスワードの勘違い、アクセス先の間違い、STARTTLS を使っているか、TLS による暗号化がうまくいっているか、などを確かめられる。~
~
+++ 接続してみる。(cf. [[openssl で smtp の STARTTLS を試す>https://bsdmad.hatenablog.com/entry/20090409/1239249624]])
 openssl s_client -connect mail.so-net.ne.jp:587 -starttls smtp
あとは同じ。~
~
+++ telnet で localhost から送信してみる。
 telnet localhst 25
あとは同様。localhost 内での送信ができることを確かめることができる。~
~
-- コメント~
+++ まずは telnet で~
telnet で一度メールを送ってみると良い。そうすると、それほど難しいことをしているわけではないことに気づく。
そこに気づけば、どこが悪いか、検討がつく。私の場合は、main.cf の中のオプションが不足していたことだった。~
~
+++ 解説サイトの記述に注意~
SASL とか TLS とか STARTTLS とかを使うのは、(1) postfix が smarthost (relay) に対してメールを投げるとき、(2) 他の MUA が自分が運用している postfix にメールを投げるとき の2通りある。main.cf のオプションも、smtp_ か smtpd_ か、といった微妙な書き分けになっているし、混乱しやすい。自分がどちらの情報を求めているのか、認識してから記事を読むとわかりやすいと思う。~
~
+++ 踏み台回避~
メールサーバを構築するときに、最も気をつけなければならないのは、踏み台にされてSPAMを全世界にばらまくのに利用されないか、ということだ。標準で、基本的には自サイトからの送信しか受け付けないようになっている。~
~
** 迷惑メールにならないために [#q3401641]
*** はじめに [#w41ad684]
- Google の迷惑メール~
GAFA などと言われて久しい。Google にはお世話になっている部分もある。しかし、Google に振り回されている部分があるのも事実だ。例えば、ウエブページについて、スマートフォンにやさしい表示でない場合に、余計なお世話なことに、それを通知してくる。しかも、きちんと対応していないとランクを下げるという。HTTP を HTTPS に変更しろとも言ってくる。メールについてもそうで、弱小のメールアドレスは、容赦なく迷惑メールに分類し、対策を強要する。もちろん、そうした方がいい、という側面はある。しかし、やり方が強引すぎる。~
- 対策と用語の紹介~
メールについては、次のような対策を行うことで迷惑メールでなくなる可能性がある。
++ SPF: Sender Policy Framework~
メールサーバがメールを受信すると、そのメールには、送信元のメールアドレスのドメイン(例えば robo.mydns.jp)と、そのメールが送られてきた計算機のIPアドレスの情報が入っている。これらが正しいかどうか、DNS(Domain Name System)に登録されたその手の情報でチェックする。つまり、DNSに、このドメインはこのIPアドレスから送信しますよ、という情報を登録しておく必要がある。~
以下の例は、Sendgrid の[[送信ドメインを認証するためのSPFレコードに詳しくなろう>https://sendgrid.kke.co.jp/blog/?p=3509]]に掲載されている例である。
“v=spf1 ip4:12.34.56.78 include:example.com -all“
~
++ DKIM: Domainkeys Identified Mail~
送信元には秘密鍵があって、その秘密鍵を使って暗号化してある電子署名は、公開鍵を使って初めて復号できる(元に戻せる)。DKIMでは、送信側の秘密鍵で暗号化したデジタル署名をメールに付加して送信する。受信側は、DNSに登録された公開鍵を使って、復号を試み、これが成功すれば、正しい送信元からのメールと判断する。~
メール全体について電子署名をつけるのは、長さの観点から正しくない。From, Date, Subject などが公開鍵でのみ復号化される暗号として送られるようである。~
~
++ DMARC: Domain-based Message Authentication, Reporting & Conformance~
SPF, DKIM が設定されていることを前提に、これらがPASSしなかった(サイトからのメールでないと判断された)ときに、どうするかを指示する。指示内容は、DNS で与える。~
[[送信ドメイン認証技術「DMARC」によるなりすましメール対策とDMARCレポートの活用>https://www.dekyo.or.jp/info/2019/02/seminar/5684/]]による図がわかりやすい。~
https://www.dekyo.or.jp/info/wp-content/uploads/2019/01/a87493d484f1d9ea9f1470641e48c0a7-640x346.png
~
*** MyDNSでの実現 [#n63b4630]
+ SPF~
POSTFIX で設定することはない。大変お世話になっている MyDNS のDOMAIN INFOで、次のように設定する。
|Hostname(左の空欄) | Type(中央のプルダウンメニュー) | Content(右の空欄) |h
|_spf | TXT | v=spf1 +ip4:202.238.84.0/24 +a:mail.so-net.ne.jp|
+ DKIM~
-- ソフトウエアの導入
 sudo apt-get install opendkim opendkim-tools
-- 導入後の作業
--- コマンドラインで実行~
example.com は適宜書き換える。-b 1024 は、後々、公開鍵を短くするため。
 opendkim-genkey -D /etc/dkimkeys/ -d example.com -s mail -b 1024
 chown opendkim.opendkim /etc/dkimkeys/*
 chmod go-rwx /etc/dkimkeys/*
 sockdir=/var/spool/postfix/var/run/opendkim
 mkdir -p $sockdir
 chown opendkim. $sockdir
 chmod go-rwx $sockdir
 chmod g+x $sockdir
--- /etc/opendkim.conf~
Socket の記述を次のように書き換える。
 Socket                  local:/var/spool/postfix/var/run/opendkim/opendkim.sock
次の2行を書き加える。
 KeyTable        file:/etc/dkimkeys/keytable
 SigningTable  refile:/etc/dkimkeys/signingtable
--- /etc/dkimkeys/keytable~
次を書き加える。example.com は適宜書き換える。
 mail._domainkey.example.com example.com:mail:/etc/dkimkeys/mail.private 
--- /etc/dkimkeys/signingtable~
次を書き加える。example.com は適宜書き換える。
 *@example.com mail._domainkey.example.com
--- /etc/dkimkeys/trustedhosts~
 127.0.0.1
--- コマンドラインで実行
 service opendkim restart
 adduser postfix opendkim
--- /etc/postfix/main.cf~
次の行を書き加える。
 milter_default_action = accept
 milter_protocol = 6
 # from inside the chroot, the socket will be in /var/run/opendkim 
 smtpd_milters = unix:/var/run/opendkim/opendkim.sock
 non_smtpd_milters = unix:/var/run/opendkim/opendkim.sock
--- コマンドラインで実行
 service postfix restart
--- MyDNS~
大変お世話になっている MyDNS のDOMAIN INFOで、次のように設定する。
|Hostname(左の空欄) | Type(中央のプルダウンメニュー) | Content(右の空欄) |h
|mail._domainkey | TXT | v=DKIM1; k=rsa; p=(MIからはじまる/etc/dkimkeys/mail.txtの文字列)|
~
-- チェック
+++ opendkim によるチェック~
次のコマンドを実行して ok が出るか?example.com は適宜書き換えて実行すること。
 opendkim-testkey -d example.com -s mail -vvv
+++ DNS チェック~
example.com は適宜書き換える。
 nslookup -type=TXT mail._domainkey.example.com
+++ メールを送信してチェック~
check-auth@verifier.port25.com にメールを送信すると、チェック結果を返信してくれる。~
+++ 普通にメールを送信してチェック~
受信したメールのヘッダを見る。~
~
エラーは出ないが、送信したメールのヘッダにDKIMの情報が含まれない。私の場合は、 [[KeyTable>./]]、[[SigningTable>./]] の記載が足りていなかった。~
→ うまくいくようになった。~
~
+ DMARC~
-- POSTFIXの設定~
まず、/etc/postfix/main.cf に alias に関する記述があること、それが、hash:/etc/aliases となっていることを確認する。~
dmarcのエントリー
 dmarc: root
を作って、これを有効にしてメール受信に備える。
 postalias /etc/aliases
 newaliases
~
-- DNS にエントリーを追加する。~
下記の example.com は適宜書き換える。
|Hostname(左の空欄) | Type(中央のプルダウンメニュー) | Content(右の空欄) |h
|_dmarc |TXT| v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com |
quarantine は、問題があるメールは隔離するように、という指示である。rua=mailto: で統計レポートの送信先を、ruf=mailto: でエラー情報の送信先を指定する。~
~
*** Google に迷惑メールに入れないように通知する [#vb077198]
- はじめに~
これだけやっても、迷惑メールに分類される場合には、直接、Google に連絡していみる。[[Gmailでスパム扱いされるときの対処方法>https://qiita.com/miwato/items/7316e55ebd2ce5a0261c]]を参考にする。~
~
*** Google Postmaster Tool [#q9801a09]
- はじめに~
Google は、メールの「迷惑メール率」を測るサービスを提供している。[[自社のメールがGmailでどれだけスパム判定されてるか、グーグルのPostmaster Toolsで調べてみた>https://webtan.impress.co.jp/e/2015/08/25/20863]]参照のこと。~
~
- 手続き~
https://postmaster.google.com にアクセスして、手続きを進める。DNS の TXT データの追加が求められる。~
~
** 参考資料 [#re4694ed]
*** POSTFIX [#ccbcc71a]
+ POSTFIX について
++ [[Postfix Documentation>http://www.postfix.org/documentation.html]]~
~
+ POSTFIX で リレー(smarthost)を使う。~
++ [[Debian ネットワークアプリケーション(6章)>https://www.debian.org/doc/manuals/debian-reference/ch06.ja.html#_the_configuration_of_postfix_with_sasl]]
++ [[Postfix でメールリレーの設定 (SMTP クライアント + SMTP Auth)>http://www.maruko2.com/mw/Postfix_%E3%81%A7%E3%83%A1%E3%83%BC%E3%83%AB%E3%83%AA%E3%83%AC%E3%83%BC%E3%81%AE%E8%A8%AD%E5%AE%9A_(SMTP_%E3%82%AF%E3%83%A9%E3%82%A4%E3%82%A2%E3%83%B3%E3%83%88_%2B_SMTP_Auth)]]
~
~
*** DKIM [#g5092148]
+ Debian で POSTFIX + DKIM
++ [[debian で opendkim>https://wiki.debian.org/opendkim]]
*** Google のレポート [#e48c7eca]
+ [[配信中のメールの暗号化>https://transparencyreport.google.com/safer-email/overview?hl=ja]]~
既に、90%程度が暗号化されている。しかし、携帯電話各社のメールの暗号化は進んでいない。~
~
+ [[ウェブ上での HTTPS 暗号化>https://transparencyreport.google.com/https/overview?hl=ja]]~
ここ5年で、50%から90%に上昇してきている。~
~

トップ   編集 差分 添付 複製 名前変更 リロード   新規 単語検索 最終更新   ヘルプ   最終更新のRSS