iredmail運用メモ 2019/12/06版


qmail+vpopmailの環境からpostfix+dovecot+iredmail環境にテスト移行してもうすぐ1年、本稼働させて5ヶ月経ちました。

いろいろ行った対処についてのまとめです。

その1: Windows Live Mail 2012ユーザがいる場合の問題

iredmailの標準設定ではWindows Live Mail 2012でのPOP3アクセスによるメール受信に失敗します。原因はWindows Live Mail 2012はSSL無し+メールパスワードを平文で送ってしまうが、iredmail側では平文拒否+SSLのみ受付、という設定であるため拒否されているためです。

また、メール送信時も、Windows Live Mail 2012がメールサーバに送るホスト名情報(HELOコマンド)がiredmailが期待する書式になっていないために拒否されます。

この2点を解消するためにdovecotの設定と、postfixの設定を変更する必要があります。詳細は下記を参照のこと。

詳細:[postfix/dovecotメールサーバでWindows Live Mail 2012がエラーになる]

その2: WebメールのRoundcubeをアップデートする場合の問題

iredmailではWebメールとしてRoundcubeSOGoを利用できます。

SOGoはRPM提供なのでアップデートは簡単ですが、Roundcubeはphpコマンドを利用してのアップデートとなっています。

しかし、iredmail標準設定ではセキュリティ強化のphp設定がされているため、Roundcubeのアップデートスクリプトが必要とするphpの機能が使用できない状態となっています。

phpの設定を変更せずにroundcubeのアップデートスクリプトを実行するには下記を参照してください。

詳細:[php.iniを変更せずにdisable_functionsの内容を無効化してroundcubeのアップグレードスクリプトを動作させる方法]

その3: 自サーバ以外で送信されたメールが受信拒否になる問題

iredmail標準設定では、iredmailサーバ以外から送信された自ドメインメールを受信拒否します。

これは、iredapdの機能で拒否しています。

iredapdの設定にSPFレコードに登録されているサーバからの送信であれば許可する、という設定があるのでそれを有効にして回避します。

詳細:[postfixを使用したiredmailで他サーバで送信された自ドメインメールが受信拒否される]

その4: Barracudacentralがメールを拒否しすぎる問題

本格運用しはじめてからログを確認してみると、BarracudacentralのSPAMデータベースを参照にしたメール受信拒否率がとても高いことが判明。

ちょっとでも疑われたら登録されているレベルのようなので誤爆率がかなり高い。特に中小企業からのメールと(ちゃんとした)メルマガ系での拒否率が高すぎた。

このため、うちのサイトの運用ではbarracudacentralの使用はやめて、spamhaus.orgのみの運用にしている。

[iRedMailの初期設定から変えたところ 2018/08/21版]

その5: mail.goo.ne.jpメールが拒否される問題

iredmailが用意している/etc/postfix/helo_access.pcreを見てみると、なんとmail.goo.ne.jpメールが明示的に拒否されていた。

いったい過去に何をやらかしたのか・・・と驚愕しつつも受信できるように設定変更している。

[iRedMailの初期設定から変えたところ 2018/08/21版]

その6: ホスト名にIPアドレスっぽい文字列が入っていると拒否される問題

SPAMを送信してくるIPアドレスについてホスト名を調べて見るとIPアドレスっぽいホスト名( network-192-168.0.100.ぷろばいだ.ne.jp )であることが多い。

このため、iredmail標準設定ではこういったホスト名からのメールは拒否しているが、拒否ログを確認してみると、Amazon AWSサービスを使っているところからのメールが結構そんな感じのホスト名で送られていて、拒否率も高かった。

このため、IPアドレスっぽいホスト名からのメールは拒否、という設定を外した。

[iRedMailの初期設定から変えたところ 2018/08/21版]

その7: メールがすぐに届かず30分程度遅延する問題

SPAMメールの送信システムは再送処理は行わず、送信できなかったらすぐに次を送るような実装になっていることが多い。

このため、iredmailでは1回目の送信処理では、今忙しいからあとでもう1回送って、と返して、15分後から受信するようになっている。

しかし、分かっているドメインからのメールだったらすぐに受信できるようにしたい、という場合はwhitelistdomainを設定することで、該当するドメインでDNSのSPFレコードに登録されているメールサーバからのメールであればすぐに受信する、という設定を行っている。

[iRedMailの初期設定から変えたところ 2018/08/21版]

その6: vpopmailからユーザパスワードを移行した場合の問題点

これは該当する人があまりいないと思いますが、vpopmailで使っていたパスワード文字列(MD5エンコード)をそのままiredmailに持ってくると、dovecotとpostfixでは使えます。

しかし、SOGoとiredmailの管理画面ではSHA256エンコードであると想定した処理となっているため使えず、ログインできません。

これはどうしようもないので、パスワードを再設定してください。

[ユーザバックエンドがSQLのiredmailのSOGoでユーザがログインできない]

RoundcubeでUID THREAD Internal error occurredが出た


iRedmailによる統合メールサーバ環境でRoundcubeによるWebメール機能を使っていたら、一部のアカウントで「UID THREAD : Internal error occurred」といったエラーがでた。

iRedmail環境ではRoundcubeのログ、というより、IMAPアクセス時のログを追う感じで調査する必要があり、該当のログは /var/log/dovecot/imap.log にあった。

Jul 25 09:34:29 サーバホスト名 dovecot: imap-login: Login: user=<メールアドレス>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=19537, secured, session=
Jul 25 09:34:29 サーバホスト名 dovecot: imap(メールアドレス): Logged out in=60 out=804
Jul 25 09:34:31 サーバホスト名 dovecot: imap-login: Login: user=<メールアドレス>, method=PLAIN, rip=127.0.0.1, lip=127.0.0.1, mpid=19541, secured, session=<9T/TlnaOYtB/AAAB>
Jul 25 09:34:31 サーバホスト名 dovecot: imap(メールアドレス): Error: open(/var/vmail/vmail1/ドメイン名/a/c/c/account//Maildir/cur/1549258275.M236704P2463.サーバホスト名,S=5291,W=5417:2,) failed: Permission denied (euid=150(vmail) egid=2000(vmail) missing +r perm: /var/vmail/vmail1/ドメイン名/a/c/c/account//Maildir/cur/1549258275.M236704P2463.サーバホスト名,S=5291,W=5417:2,)
Jul 25 09:34:31 サーバホスト名 dovecot: imap(メールアドレス): Logged out in=94 out=1035

えーと・・・

[root@ホスト名 ~]# ls -l /var/vmail/vmail1/ドメイン名/a/c/c/account//Maildir/cur/1549258275*
-rw------- 1 root root 5291  2月  4 14:35 /var/vmail/vmail1/ドメイン名/a/c/c/account//Maildir/cur/1549258275.M236704P2463.サーバホスト名,S=5291,W=5417:2,
[root@ホスト名 ~]#

なんでだろう???

とりあえずchownでvmail:vmailに変えて解決しました。

ユーザバックエンドがSQLのiredmailのSOGoでユーザがログインできない


qmail+vpopmailからパスワード暗号化文字列ごと移植したpostfix+dovecotベースの統合環境iredmail環境がある。

iredmailにはExchange互換サーバのSOGoもあるので、そちらでログインしようとしたらエラーになる。

roundcubeからだとログインができるし、dovecotを使うPOP3/IMAPアクセスでも問題無い。

/var/log/sogo/sogo.log へのエラーは下記の様になっていた。

Jul 04 13:15:04 sogod [9257]: SOGoRootPage Login from 'クライアントIPアドレス' for user 'ユーザ名@ドメイン名' might not have worked - password policy: 65535  grace: -1  expire: -1  bound: 0

iredmailのフォーラムに「Can’t configure password policy when using SOGo」といのがあり、sogo.confに「passwordPolicy = YES;」を追加すればいいじゃん?とあったのでやってみたが、変化はなし。

SOGo側のbug tracking system「 0003899: SQL authentication 」にてヒントを発見。

暗号化文字列の指定の問題のようだ。

今回、sogo.confは下記の様に「userPasswordAlgorithm = ssha512」となっており、パスワード暗号化文字列がssha512フォーマットである、ということになっている。

    SOGoUserSources = (
        {
            type = sql;
            id = users;
            viewURL = "mysql://sogo:~@127.0.0.1:3306/sogo/users";
            canAuthenticate = YES;

            // The algorithm used for password encryption when changing
            // passwords without Password Policies enabled.
            // Possible values are: plain, crypt, md5-crypt, ssha, ssha512.
            userPasswordAlgorithm = ssha512;
            prependPasswordScheme = YES;

            // Use `vmail.mailbox` as per-domain address book.
            isAddressBook = YES;
            displayName = "Domain Address Book";
            SOGoEnableDomainBasedUID = YES;
            DomainFieldName = "domain";
        },

しかし、今回、vpopmail時代の文字列「$1$5ulpxxxx$VS0xHxxKxMPBSIPQlXDXC/」という書式、つまりはmd5-cryptフォーマットを流用しているので認証できなかった、ということになる。

メインとなるiredmail側は新しくパスワードを設定した場合はssha512、移植したものはmd5-cryptという運用にしている。

ただ、postfix,dovecot,roundcubeの運用に関しては、ssha512でもmd5-cryptでも問題無くログインできている。

それに対してSOGo側は「SOGO Installation and Configuration Guide」を見ると userPasswordAlgorithm には1つの値しか指定はできないようだ。

セキュリティを考えると全体をmd5-cryptに下げる、という選択肢はとれないので、SOGoを使いたい場合は、パスワードを再設定する、ということになる。

パスワードを再設定すると以下のログとなる。

Jul 04 13:50:43 sogod [1094]: SOGoRootPage successful login from 'クライアントIPアドレス' for user 'ユーザ名@ドメイン名' - expire = -1  grace = -1

iRedMailの初期設定から変えたところ 2018/08/21版



postfix+dovecotを使って複数ドメインのメールサーバを簡単にできるようにしたパッケージ「iRedMail」を利用中。

1月から流量が少ないドメインで使用を開始し、夏頃から本格利用を開始した。
中小企業相手のメールが多くなるとiRedMailの標準設定では、先方からのメール受け取りが拒否されることが増えてきた。
その他にも、メールサーバ以外の場所からメールを送信する場合に受け取り拒否が発生するということもあった。

そこで、日本で使う場合に受信出来ないということが少なくなるような設定ポイントを解説してみる


(1) メールサーバ以外の場所からメールを送信する場合、iredapdの設定を変える
メールサーバ以外にあるWebサーバや、Yahooや楽天などのシステムから自社ドメインのメールを送りたい場合、iRedMail標準設定では、メール受信がSMTP AUTHされてないサーバから送られてきてると拒否されてしまう。(Recipient address rejected: SMTP AUTH is required for users under this sender domain)
これは、iredapdのポリシーによる設定であるため、ルールを変更することで対処ができる。

なお、設定変更する前に、メール送信するサーバがSPFレコードに登録されていることを確認する。

設定は、/opt/iredapd/settings.py に「CHECK_SPF_IF_LOGIN_MISMATCH = True」を追加して、iredapd.serviceを再起動することで完了する。

参考:「postfixを使用したiredmailで他サーバで送信された自ドメインメールが受信拒否される


(2) barracudacentralを使わない
iRedMailの標準設定では「zen.spamhaus.org」と「b.barracudacentral.org」の2つがSPAM拒否データベースとして使われている。
ただ、いろいろ運用してみると、spamhaus.orgの方は一般住宅回線にあるSPAM botからのメールを効率良く排除してくれるが、
barracudacentral.orgの方は、どうも誤爆が多いようで、中小企業からのメールが良く拒否リストに入ってしまっている。
(たぶん共有サーバ運用で、他のユーザが変なことしたせい)

なので、うちではbarracudacentralを使用しないようにしました。

設定は「/etc/postfix/main.cf」で「postscreen_dnsbl_sites = 」で設定されているものから「b.barracudacentral.org=127.0.0.[2..11]*2」の記述を消すだけです。


(3) mail.goo.ne.jpからのメールが拒否されているのでコメント
/etc/postfix/helo_access.pcre にある設定によりmail.goo.ne.jpからのメールが拒否されているので、設定を変更する

変更前

/^(mail\.goo\.ne\.jp)$/ REJECT ACCESS DENIED. Your email was rejected because it appears to come from a known spamming mail server (${1})

変更後

###/^(mail\.goo\.ne\.jp)$/ REJECT ACCESS DENIED. Your email was rejected because it appears to come from a known spamming mail server (${1})

(4) ホスト名にIPアドレスが含まれていると拒否する設定があるので、設定を一部変更する。
家庭用回線などnetwork-192-168.0.100.ぷろばいだ.ne.jpという感じでIPアドレスがもろに埋め込まれたホスト名が使われている。
それに対して、メールサーバは多くの場合、ちゃんと命名されていることが多い。

が・・・AmazonのAWSでサービスを立てているようなところからのメールが、IPアドレス付きのメールサーバから送られてくる事がある。
また、それ以外でも、ちらほらと・・・

/etc/postfix/helo_access.pcre の設定によるもので、下記のbypassの後に記述を追加する

変更前

# bypass "[IP_ADDRESS]"
/^\[(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\]$/ DUNNO
# reject HELO which contains IP address
/(\d{1,3}[\.-]\d{1,3}[\.-]\d{1,3}[\.-]\d{1,3})/ REJECT ACCESS DENIED. Your email was rejected because the sending mail server appears to be on a dynamic IP address that should not be doing direct mail delivery (${1})

変更後

# bypass "[IP_ADDRESS]"
/^\[(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\]$/ DUNNO
### add by 2018/08/09 for yawata-lions.com
/^sv(\d{1,3}-\d{1,3}-\d{1,3}-\d{1,3}).*.seedshosting.jp$/ DUNNO
### add by 2018/08/09 for aws servers
/^ec2-(\d{1,3}-\d{1,3}-\d{1,3}-\d{1,3}).*.amazonaws.com$/ DUNNO
### add by 2018/08/09 for shop-pro.jp
# mail-10-200-1-137.mitaka.shop-pro.jp
/^mail-(\d{1,3}-\d{1,3}-\d{1,3}-\d{1,3})/ DUNNO
# reject HELO which contains IP address
/(\d{1,3}[\.-]\d{1,3}[\.-]\d{1,3}[\.-]\d{1,3})/ REJECT ACCESS DENIED. Your email was rejected because the sending mail server appears to be on a dynamic IP address that should not be doing direct mail delivery (${1})

(5) whitelistdomainを登録しておく
iRedMailだと、greylistを採用しており、メールが送られてくると最初の5分間はメールを受け取らず、再送されてくると受け取るようになっている。
しかし、ある程度信頼がおけるドメインのSPFレコードに登録されているサーバから送られてくるメールは、最初から受け取ってしまうようにした方がログチェックも簡単になる。

現在登録されている一覧は「/opt/iredapd/tools/spf_to_greylist_whitelists.py」を実行して確認できる。
登録は「/opt/iredapd/tools/greylisting_admin.py –whitelist-domain –from ‘@docomo.ne.jp’」というようにドメイン名を指定して行う。
ただ、コレはデータベースに登録するだけで、システムへの反映は「/opt/iredapd/tools/spf_to_greylist_whitelists.py」を実行する必要がある。
標準設定では毎時2分に実行されている。

うちのサーバで追加登録したものを下記に上げておく。便利なようにコマンドとしてそのまま実行できる状態にしておきます。

# 携帯電話のメールアドレス
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@docomo.ne.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@ezweb.ne.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@i.vodafone.ne.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@k.vodafone.ne.jp'

# ネットサービス系
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@mixi.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@magb.netmile.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@mrelay.epark.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@mta14.dmm.com'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@fmail01.gpoint.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@post.freeml.com'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@post.point.gmo.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@receive.mag2tegami.com'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@return.mag2-tayori.com'

# ショップ系
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@amazon.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@jmg.joshin.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@ma.store.uniqlo.com'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@return.nttxstore.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@webmail.askul.co.jp'

# 楽天関連
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@rakuten.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@emagazine.rakuten.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@mail.travel.rakuten.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@shop.rakuten.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@tc.api.rakuten-card.co.jp'

# Yahoo
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@err.yahoo.co.jp'

# 企業系
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@amc.ana.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@m1.kirin.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@olympus-imaging.com'

# 銀行・金融系
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@ct.shinseibank.com'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@mdbc.jibunbank.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@m.email.americanexpress.com'

# その他
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@a8.net'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@bounces1.postcarrier.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@d00.mailsystem.anser.ne.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@infomart.co.jp'
/opt/iredapd/tools/greylisting_admin.py --whitelist-domain --from '@willap.jp'

yahoo.co.jpのメールサーバは管轄ドメイン外でもメールが送れてしまう?


メールシステムを新しくしたのでメールログを監視中。

そんななか不審なものが・・・

Aug  9 07:48:48 サーバ名 postfix/smtpd[7394]: NOQUEUE: reject: RCPT from mta094.mail.bbt.yahoo.co.jp[182.22.12.65]: 450 4.1.8 <glfruwj@zrbzzfmaewphpyi.jp>: Sender address rejected: Domain not found; from=<glfruwj@zrbzzfmaewphpyi.jp> to=<宛先メールアドレス> proto=SMTP helo=<mta094.mail.bbt.yahoo.co.jp>

Aug  9 07:55:19 サーバ名 postfix/smtpd[7394]: NOQUEUE: reject: RCPT from mta008.mail.bbt.yahoo.co.jp[182.22.12.11]: 450 4.1.8 <fvawxvd@6vo07bbmyz8wa8d.jp>: Sender address rejected: Domain not found; from=<fvawxvd@6vo07bbmyz8wa8d.jp> to=<宛先メールアドレス> proto=SMTP helo=<mta008.mail.bbt.yahoo.co.jp>

yahoo.co.jpのメールサーバを使って、SPAMドメインからのメールを配信しようとしている形跡が・・・

え・・・自社ドメイン以外でも送れる設定にしてるんですか!?

もしかして、Yahooショッピングのテナントが、それぞれ自社ドメインで送れるようにそうなってるんですかね?

さすがに送信時にSMTP AUTHをしていないとは思えないし、いったいどういう処理をしてるんだかなぁ・・・


2019/06/18追記

今日も元気に、mta???.mail.bbt.yahoo.co.jpやmta???.mail.djm.yahoo.co.jpから存在していないドメインがFromに設定されているSPAMメールが送信中です。

[root@サーバ名 ~]# grep "NOQUE" /var/log/maillog|grep yahoo.co.jp|grep "Domain not"
<略>
Jun 18 14:25:52 サーバ名 postfix/smtpd[31047]: NOQUEUE: reject: RCPT from mta009.mail.bbt.yahoo.co.jp[182.22.12.12]: 450 4.1.8 <nmroofhyu@wqk5z43zgjb5y.net>: Sender address rejected: Domain not found; from=<nmroofhyu@wqk5z43zgjb5y.net> to=<宛先メールアドレス> proto=SMTP helo=<mta009.mail.bbt.yahoo.co.jp>
Jun 18 14:35:29 サーバ名 postfix/smtpd[32576]: NOQUEUE: reject: RCPT from mta718.mail.djm.yahoo.co.jp[183.79.16.21]: 450 4.1.8 <kqqtlikg@pxnfykriyoxywkrdum.jp>: Sender address rejected: Domain not found; from=<kqqtlikg@pxnfykriyoxywkrdum.jp> to=<宛先メールアドレス> proto=SMTP helo=<mta718.mail.djm.yahoo.co.jp>
[root@サーバ名 ~]# grep "NOQUE" /var/log/maillog|grep yahoo.co.jp|grep "Domain not"|wc
     66    1518   20892
[root@サーバ名 ~]#