Courier MTA

提供: ArchWiki
Courierから転送)
ナビゲーションに移動 検索に移動

関連記事

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/authdaemonrcauthuserdb だけを許可したため、仮想メールシステムユーザーの属性を保存する必要があります。クーリエには全てのローカルユーザーをクーリエの構文で書かれたファイルに変換するスクリプトが付属しています。名前は何でもかまいません (以下では "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
ノート: Any subdomain like project1.my-cool-domain.ca or smtp.my-cool-domain.ca also must also be in /etc/courier/hosteddomains if you want to have email addresses like info@project1.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
ノート: [TAB] can be inserted by typing 'Ctrl' + V then 'Tab'

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 @.