Courier MTA
関連記事
Courier MTA はクーリエによる SMTP や POP3/IMAP4 のサーバーです。
Courier-MTA の特徴:
- MTA や POP3/IMAP の認証をひとつにまとめることができます。
- 認証源としては MySQL, PgSQL, LDAP あるいは PAM やプレーンテキストファイル (BerkeleyDB) など様々な方法が使えます。
- 仮想ユーザーのサポート。
- SMTP 認証が初めから使えます。
- ウェブメールが付属。
- ウェブベースの管理が可能。
- 必要であれば別のメール配送エージェント (MDA) が使えます。
目次
インストール
courier-mtaAUR パッケージをインストールしてください。
他のメール転送エージェント (cyrus など) や smtp サーバー (sendmail や postfix) はアンインストールしてください。
Authuserdb 認証
authuserdb で認証するようにクーリエを設定します。
/etc/authlib/authdaemonrc
ファイルを開いて authmodulelist=...
という部分を探して authuserdb 以外のモジュールを全て削除してください:
authmodulelist="authuserdb" # For test it is useful to set DEBUG_LOGIN from 0 to 2 DEBUG_LOGIN=2
仮想メールユーザーの作成
メールを仮想ユーザーに配送することで、実際のユーザーを作成することなく簡単にメールアカウントを作成できるようにします。メールを読むのに ssh でアクセスする必要はありません。そのためには物理的なユーザーがひとつだけ必要です。
全てのメールファイルを保存するために "vmail" ユーザーを追加してください:
# useradd -u 7200 -m -s /bin/bash vmail # passwd vmail
メールアカウントの作成
仮想ユーザーと属性をプレーンテキストファイル、あるいは複数のテキストファイルが含まれているディレクトリに保存します。詳しくは courier-authlib のドキュメントを読んでください。ディレクトリを使用する場合はドメインやサブドメインのユーザーを分割できるためメンテナンスが楽になります。ディレクトリの名前は固定です。
# mkdir /etc/authlib/userdb
/etc/authlib/authdaemonrc
で authuserdb だけを許可したため、仮想メールシステムユーザーの属性を保存する必要があります。クーリエには全てのローカルユーザーをクーリエの構文で書かれたファイルに変換するスクリプトが付属しています。名前は何でもかまいません (以下では "system" としています)。後で "domain1" と "domain2" のファイルも作成します。
# pw2userdb > /etc/authlib/userdb/system
"vmail" ユーザーだけ残します (他のローカルユーザーはメールを受信できなくなります):
# sed -n -i "/vmail/p" /etc/authlib/userdb/system
次に認証データベースに仮想ユーザーを作成します。実際の Maildir フォルダは後で手動で作成してください。ここでは "user1@domain1" と "user2@domain2" ユーザーを作成します。コマンドについて詳しくは man ページを見てください。
- user1:
# userdb -f /etc/authlib/userdb/domain1 user1@domain1 \ set home=/home/vmail/domain1/user1 uid=7200 gid=7200
ユーザーのパスワードを設定 (PLAIN, LOGIN, APOP を使用):
# userdbpw -md5 | userdb -f /etc/authlib/userdb/domain1 user1@domain1 set systempw
以下は CRAM-MD5 (SASL) を使う場合の例です。パスワードを直接コマンドにパイプして平文で読めるようにすることで新しいユーザーを作成するシェルスクリプトから使えるようにしています:
# echo 'pwuser1' | userdbpw -hmac-md5 | \ userdb -f /etc/authlib/userdb/domain1 user1@domain1 set hmac-md5pw
- user2 (user2@domain2):
# userdb -f /etc/authlib/userdb/domain2 user2@domain2 \ set home=/home/vmail/domain2/user2 uid=7200 gid=7200
# userdbpw | userdb -f /etc/authlib/userdb/domain2 user2@domain2 set systempw
# echo 'pwuser2' | userdbpw -hmac-md5 | \ userdb -f /etc/authlib/userdb/domain2 user2@domain2 set hmac-md5pw
Maildir の設定
"vmail" システムユーザーのホームディレクトリに仮想ユーザーの "Maildir" を作成する必要があります。"vmail" ユーザーが書き込めるように所有者を "vmail" ユーザーにしてください。"vmail" ユーザーとして作成するのが一番簡単です。
"vmail" でフォルダを作成:
# su vmail $ mkdir -p /home/vmail/domain1/user1 && maildirmake /home/vmail/domain1/user1/Maildir $ mkdir -p /home/vmail/domain2/user2 && maildirmake /home/vmail/domain2/user2/Maildir
作成後 "vmail" アカウントから抜けてください:
$ exit
ユーザーデータベースの作成
次に平文のテキストファイルから BerkeleyDB を作成します。/etc/authlib/userdb
のファイルは root からしか読み込めません。誰からでも読み込めたりグループの権限が設定されていた場合、クーリエは DB ファイルの作成を許可しません。
# chmod 700 /etc/authlib/userdb && chmod 600 /etc/authlib/userdb/* # makeuserdb
そして認証が機能することを確認します。クーリエにはユーザーが認証できるかどうか確認するためのツールが付属しています。ツールを使用する前に authdaemond.service
を起動・有効化して認証デーモンを起動し、以下のコマンドを実行してください:
# authtest user1@domain1 # authtest user2@domain2
認証のテスト時に何かエラーが発生する場合、[1] に問題を確認するためのデバッグ機能の使用方法が載っています。
クーリエの設定
認証の設定が完了したらクーリエの設定に移ります。まず、サーバーのエイリアスを指定します。エイリアスは userdb と同じように記述できます。他のメールサーバーと違って、エイリアスをひとつのファイルにまとめる必要はありません。特定のフォルダに複数のプレーンテキストファイルを作成して、ドメインごとにエイリアスを管理できます。フォルダの場所は固定です。/etc/courier/aliases
を使ってください。root や postmaster などの設定をする "system" ファイルが既にあるはずです。既存の "postmaster: " の後ろに "user1@domain1" を追加してください。システム関連のメールは "user1@domain1" に配送されるようになります。
# cat > /etc/courier/aliases/domain1 << EOALIASES user1@domain1: user1@domain1 user.user1@domain1: user1@domain1 u.user1@domain1: user1@domain1 userer1@domain1: user1@domain1 looser1@domain1: user1@domain1 EOALIASES
ドメインとユーザーごとに繰り返し設定を行ってください。
最後に、エイリアスを BerkeleyDB に反映させます。クーリエには makealiases
という名前のユーティリティが付属しています:
# makealiases
設定に問題がないか確認:
# makealiases -chk
localdomain と hosteddomains の設定
次にクーリエに誰がメールを受け取って誰がメールを受け取らないのかマシン上のアカウントを設定します。クーリエは設定を以下のレベルに分けています:
- locals: This is localhost for sure and on dedicated servers you are mostly part of a domain like server234.serverfarm.tld
- hosteddomains: For your hosted domains and subdomains like my-cool-domain.ca, project1.my-cool-domain.ca
For example, lets say you have a server at blahfarm.com. Usually they make your server a host on their domain. This is likely something like server234.blahfarm.com . Now, you want your server available from the web by a more meaningful and even cooler name, so you buy (or rent) a domain name like my-cool-domain.ca . In this case the setup looks like this:
- locals:
- localhost
- server237.blahfarm.com
- hosteddomains:
- my-cool-domain.ca
- project1.my-cool-domain.ca
- smtp.my-cool-domain.ca
To learn the difference between these specifications, read the manpage for makehosteddomains
. You will figure that the following suits our approach:
# echo localhost > /etc/courier/locals # echo server237.blahfarm.com >> /etc/courier/locals # mkdir /etc/courier/hosteddomains # cat > /etc/courier/hosteddomains/domain1 << EODOMAIN1HOSTED domain1 mail.domain1[TAB]domain1 EODOMAIN1HOSTED # cat > /etc/courier/hosteddomains/domain2 << EODOMAIN2HOSTED domain2 mail.domain2[TAB]domain2 EODOMAIN2HOSTED
Again, these values must be converted into a BerkeleyDB - use the courier command:
# makehosteddomains
Before we go on, one more thing needs to be written -- the domain(s) we accept mail for. In the directory /etc/courier/esmtpacceptmailfor.dir/
we'll create a file named domain1
and type domain1
into it:
# echo domain1 > /etc/courier/esmtpacceptmailfor.dir/domain1
Repeat for domain2:
# echo domain2 > /etc/courier/esmtpacceptmailfor.dir/domain2
Finally, convert into a BerkeleyDB:
# makeacceptmailfor
...and you are done here.
セットアップのテスト
SMTP サーバーで複数のテストを実行してメールの送受信が問題ないことを確認してください:
############################################################################### # this is a testcase suggested on couriers very own webpage, we just convert it # from a local to a virtual user # prepare as vmail su vmail cd ~/domain1/user1 maildirmake bounces && maildirmake test echo "./test" > .courier-test-default echo "./bounces" > .courier # back to root, start the server and finally run the script exit /usr/sbin/courier start /usr/lib/courier/perftest1 1000 "user1@domain1 user2@domain2" ###############################################################################
通常のメールを送信 (root あるいは通常ユーザーで実行):
$ echo "To: user2@domain2 From: user1@domain1" | /usr/bin/sendmail
エイリアスにメールを送信:
$ echo "To: userer2@domain2 From: user1@domain1" | /usr/bin/sendmail
外部メールアドレスにメールを送信:
$ echo "To: me_freak@gmail.com From: user1@domain1" | /usr/bin/sendmail
IMAP と POP3 の設定
So far, our operations have been focused on the box which runs the server itself. Now we need to setup some interaction related configuration. Since security is important we will setup some nice authentication modes, which doesn't send cleartext passwords. Courier supports CRAM-MD5 among others. You will have to make sure that your clients support that too. So far I tested sylpheed-claws > 1.0.4, esmtp and thunderbird with these settings.
Now it comes in, that we will have to configure the several server daemons. Courier is already running (from the perftest above) but it doesn't provide services to the network. So we have to configure esmtpd, pop3d and imapd with their respective configuration files in /etc/courier/<servicename>
.
Since we like to use SMTPAuth instead if a IP/Domain based SMTP authentication we need to activate the AUTHREQUIRED option in esmtpd. Also we activate the CRAM-MD5 challenge method for authorization. NOTE: this setup definitely keeps Outlook losers out. For these buggy and old fashioned clients you will need to use way less restrictive settings!
In /etc/courier/esmtpd
:
AUTH_REQUIRED=1 ESMTPAUTH="CRAM-MD5"
In /etc/courier/pop3d
:
POP3AUTH="CRAM-MD5"
The imapd setting is a bit different. In /etc/courier/imapd
there is a long line starting with IMAP_CAPABILITY. Just add a "AUTH=CRAM-MD5" at the end of the arguments and you should be done:
IMAP_CAPABILITY="... AUTH=CRAM-MD5"
備考
Because of our very small testcase with just 2 boxes and no domaincontrol we have to take a look at couriers intrinsics and work around a little issue. Courier is nitpicking about RFC compliance, which does mean you have to make sure that you understand how to configure your e-mail clients for testing. This will fail in our testing:
+------------+ +---------------+ +-------------------+ |local laptop| -------> |local box(with | ------------> | MTA somewhere on | +------------+ | courier-mta) | | web | +---------------+ +-------------------+
Why? Because you send from a non-valid domain name. I assume here, that we use our "domain1" and "domain2" testpark. Now, when you create an account in Sylpheed which looks like this: Name: user numberone Address: user1@domain1 Sylpheed consequently sends the mail as "user numberone <user1@domain1>". This is wrong, since it violates the RFC. You get a Error: 517 - Syntax Error. For the testing you can simply fool Courier-MTA by setting the domain in sylpheed's dialog to: Address: user1@domain1.xx
Something similar (you just get Error 513 - Syntax Error) happens in this case:
+--------------------------+ +------------------------+ |local laptop | -------> |local MTA (courier-mta) | | sylpheed account | | MTA delivers to | | user1@domain1.xx sends | | user2@domain2 | | to user2@domain2 | +------------------------+ +--------------------------+
because domain2 is not valid. You can send to mail.domain2 which will work around that. For boxes at the internet and properly configured domains this is absolutely no problem, since you are always part of a domain and thus have one dot (.) behind the @.