DHCPでアドレスの割り当てを受けている場合、メールの送信サーバとして不適格とみなされ、受信先のメールサーバに受け取りを拒否される場合がある。

回避するためには、インターネットの接続プロバイダが提供するメールサーバを経由して送信するようにすればよい。

/etc/postfix/main.cf に以下のように設定する。

relayhost = [smtp.provider.hoge]

サブミッションポートへの接続が必要な場合は次のようにする。

relayhost = [smtp.provider.hoge]:587

更に、認証が必要場場合は、/etc/postfix/main.cf に次の設定を追加の上、/etc/postfix/relay_password に使用するユーザIDとパスワードを設定する。

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/relay_password
smtp_sasl_securtiy_options = noanonymous

/etc/postfix/relay_passwordの内容は以下のようになる。

[smtp.privider.hoge]   user_name@smtp.provider.hoge:xxxxxxxx

パスワードが記述されているので、パーミッションは0600にするなどして管理に気をつけること。 内容を変更したら、postmap コマンドを適用する。

# postmap hash:/etc/postfix/relay_password

SMTP認証を有効にするためには、/etc/postfix/main.cf に以下の設定を行う。

smtpd_sasl_auth_enable = yes
smtpd_sasl_auth_domain = $mydomain
smtpd_receipient_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_unauth_destination,pcre:/etc/psotfix/access_regexp,permit_auth_destination,reject

また、submissionポートからの接続に対して同様に認証を要求する場合は/etc/postfix/master.cfに対して以下のようにする。

submission inet n - n - - smtpd
 -o smtpd_sasl_auth_enable=yes
 -o smtpd_etrn_restrictions=reject
 -o smtpd_enforce_tls=yes

認証自体は、SASL2で行う。 このための設定は、/usr/lib/sasl2/smtpd.conf に以下のように記述する。 ファイルがなければ作成する。

pwcheck_method: saslauthd
mech_list: plain login cram-md5 digest-md5

ユーザとパスワードは次のようにして作成しておく。

# saslpasswd2 -c -u `postconf -h myhostname` username

パスワードはログイン用のモノとは別にするのが好ましい。

courier-imapは、長らく我が家でIMAPサービスを提供してきたが、パフォーマンスの劣化に伴い、dovecotへと交代した。

近年、標準的 IMAPサーバとしての地位を確立しつつあり、パフォーマンスやセキュリティ、また既存のIMAPサーバとの互換性の確保がおこないやすいため、乗り換えやすい。

PHPベースのウェブメイラの草分け。 プラグインで、managesieveにも対応するが、いかんせん、UIが古くさい。 また、速度もあまり速くはない。

モダンなウェブメイラ。 マルチアカウント対応で、managesieveにもβ扱いながら対応している。 但し、現在managesieve機能には問題有り。 ¹⁾ メイルの表示能力、機能の豊富さ、インストールの簡便さに秀でている。

モダンなウェブメイラ。 Debian などが標準的なプロダクトとしてパッケージ化している。 インストールの手順は煩雑。 managesieve機能は非常に安定していて、かつ、高機能。 日本語メールのデコードにやや難あり。

ウェブメイラをいくつか併用してみた感想を書いておく。

RainLoopが群を抜いて簡単である。 ファイルを配置して、Apacheからアクセス可能にしたら、あとはウェブブラウザからほとんどの設定を行う事が出来る。 サーバ上であれこれいじる必要がない。 ²⁾

逆に、RoundCubeは、ウェブ上での設定に移行するまでに、あれこれサーバ上で設定しなければならない。 また、ユーザに共通の設定に関しては、一旦、設定してしまったら、ブラウザ上からは変更できない。 一度決めた設定はそうそういじらないものかも知れないが、やや柔軟性に欠けるきらいがある。

Squirrel-Mailはサーバ上での設定こそ必要だが、CUIベースとはいえ対話型の設定アプリを用意しているのでそれほど難ではない。

インストールはさておき、使い勝手の点では、RoundCubeも悪くはない。 高速だし、managesieveによるフィルタの管理は、非常によくできている。 但し、一部日本語メールのデコードに難があり、残念ながら、RainLoopに敵わない。 また、フォルダーを丸ごと未読・既読にする操作などもなぜかない。

RainLoopは managesieveの機能に難がある ³⁾ 他は、非常に良好である。 メールのデコードも正確、操作も十分な機能があり、普段使いのメイラはこれで決まりだろうと思う。

Squirrel-Mailは、いかんせん、古くなりすぎで、上記二つと比較するべくもない。 それでも、プラグインで、managesieveに対応するなど、現役で使用することが出来ないほどには陳腐化してない。

自宅のIMAPサーバには、自宅アドレス以外にも、外部のメールアドレスで受信したメールを fetchmail 経由で取り込んで管理している。

このとき、メールの振り分けを長らく procmail で行ってきたが、ルールの可読性の低さから、IMAPサーバをdovecotに変更したついでに、Sieveでの管理に移行することにした。

但し、Sieveで標準化されているのは単純なメールの移動や、破棄、転送だけなので、procmailで行っているような、スパムフィルタやウィルススキャンの適用などを織り込むのは少々難しい。⁴⁾

そこで、従来通り、procmailにて、これら、ウィルススキャン未適用メールおよび、スパムフィルタ味通過のメールの処理を行った上で、後段として、Sieveに処理を渡すこととした。

することは単純で、ルールの一番最後にSieveでの振り分けを追加するだけである。

DELIVER="/usr/libexec/dovecot/deliver -d ${LOGNAME}"
...
# Virus scan is applied if the mail has not applied it.
:0HB
*!^X-Virus-Scanned: .*wildtree\.jp$
*! ? /usr/bin/clamdscan --quiet -
$VIRUS

# Spam filter is applied if the mail has not applied it.
:0fw
*!^X-Spam-Status.*
|/usr/bin/spamc

# dispatch rules
...
# process by dovecot-sieve
:0w
| ${DELIVER}

あとは、Sieve 側に、振り分けルールを移行し、procmail側からそれらを除去するだけである。

基本的に、自宅サーバで受信されたメールは、amavis-new によって、ClamAVおよびSpamAssassinを通されているが、fetchmailで外部からpop3経由で取り込んできたメールは、その保証の外である。

そこで、ヘッダをチェックし、これらの痕跡がないものについては、チェックを行ってから振り分けに回すようにしている。

外部のアドレスから pop3ではなく、転送で、自宅アドレスに送ればこの問題はないので、最初から、deliver に回してしまってよい。

VineLinuxに関して