qmailの情報収集 2019/08/26


うちはqmailを使わなくなったけど、使っていた当時に書いた2016年の「qmailの情報収集 2016/03/31」と2012年の「いまさらqmailのパッチ情報収集 2012/02/17」には、いまでもちらほらアクセスがある。

で・・・最近、qmail的に大ニュースがあったので久々に情報更新。

期待の新星「notqmail」リリース

1998年6月リリースのqmail v1.03に対するパッチをまとめたnetqmail がv1.04として2003年10月にリリースされた。しかし、netqmailは2007年11月のv1.06を最後に更新が無くなった。

今回、qmailでもnetqmailでもないものとして、notqmailがv1.07としてリリースされた。

ゆくゆくはいろんな機能を取り入れることになっていく予定ですが、現状では有名どころの既存qmailパッチ間の差異が大きいようで、notqmailのブランチとして各パッチ適用済みバージョンも提供されている。(詳細は公式ページのPatchesを参照のこと)

BranchOriginal Patch
notqmail-badmailfrom-wildcardTom Clegg’s badmailfrom wildcard
notqmail-badmailfrom-x-relayclientJeremy Kitchen’s badmailfrom-x-relayclient
notqmail-big-concurrencyJohannes Erdfelt’s big-concurrency
notqmail-big-todoRussell Nelson’s big-todo
notqmail-dns-any-to-cnameJonathan de Boyne Pollard’s any-to-cname
notqmail-dns-oversizeChristopher K. Davis’s oversize DNS packet
notqmail-ext-todoAndré Opperman’s ext_todo or “silly qmail syndrome”
notqmail-smtp-authErwin Hoffmann’s smptauth
notqmail-smtp-tlsFrederik Vermeulen’s qmail-smtp-tls
notqmail-smtpd-loggingAndrew Richards’ qmail-logmsg
notqmail-smtpd-spfJana Saout’s qmail-spf

「s/qmail」は細々運営中?

2016年に公式リリースされた「s/qmail」は、2019年6月のv3.3.23が最新リリースとなっている。

ただ、作者のnewsページを見てみると「aqmail is a joint project of Erwin Hoffmann (s/qmail) and Kai Peter (eqmail) to provide an alternative Qmail. Coming soon.」として「aqmail」というものを始めるらしい。

qmail開発者2人によるジョイントプロジェクト「aqmail」

aqmail is a joint project of Erwin Hoffmann (s/qmail) and Kai Peter (eqmail) to provide an alternative Qmail. Coming soon.」として「aqmail」 が2017年に開始されている。

が・・・githubのレポジトリ https://github.com/aqmail/aQmail は全然更新されていないが、元となるs/qmailとeQmailは更新されているという・・・

qlibというeQmail作者が作ったライブラリを利用している。

「eQmail」

サイトとしては「openQmail」という名称となっている。

元のqmailは内部で「djb’s libs」と呼ばれるdjbが作成したライブラリ群を使用しているがこれらはあくまでqmail内部でのみ使われているようなものだった。これを単体ライブラリ化したものがlibdjb(最終リリース2000年10月)となる。そして、このライブラリをGPLとして再実装したものが libowfat(最新リリース2018年10月)というものとなる。

libowfatとdjb’s libsをeQmail作者が使いやすいように実装し直したものが qlib というライブラリになるようで、eQmailではコレを使用している。

こちらは2019年8月リリースのeQmail-1.10.1が最新となっている。

「IndiMail」

IndiMail」という公式ページがあるが管理状況が怪しい。

SOURCEFORGEのIndiMailプロジェクトページを見てみるとそこそこ更新されている。

qmail部分であるindimailパッケージのバージョンとしては2018年10月リリースのindimail v2.6が最新であるようだ。

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'

いまどきメールヘッダのReceived fromに(unknown~)って出るのださくね?



メールシステムを新しくしたので、メールログの監視強化中。
そんななかで見つけたベストリザーブのDMがかなりアレ。

Received: from ptmag3.bestrsv.com (unknown [211.133.130.68])
とか
Received: from ptmag5.bestrsv.com (unknown [211.133.130.68])
とか

内部IPアドレスについて、unknownになる例はちらほらあるけど、インターネットに接続されているIPアドレスを持つメールサーバでコレは珍しい。

過去に届いたメールを漁ると、内部の実サーバ名として以下の6種類があったようだ。
ptmag.bestrsv.com
ptmag1.bestrsv.com
ptmag2.bestrsv.com
ptmag3.bestrsv.com
ptmag4.bestrsv.com
ptmag5.bestrsv.com

また、メールサーバのログを追うと、HELOコマンドでは下記のホスト名を送ってきていた。
sitsmtp.bestrsv.com

どうも内部では複数のサーバに分かれていて、sitsmtp.bestrsv.com(211.133.130.68)からインターネットに出てきているようだ。
しかし、これらのホスト名に対してIPアドレス(Aレコード,AAAAレコード)は全て設定されていない。
211.133.130.68の逆引きホスト名はsitsmtp.bestrsv.comが設定されているが、sitsmtp.bestrsv.comでは名前解決ができない。

なお、2011/12/05の「 ベストリザーブ・宿ぷらざ オープンしました☆(2011/12/05)」のメールを見ると、ちゃんとAレコードが設定されていた形跡はある。

Received: from ptmag.bestrsv.com (sitsmtp.bestrsv.com [211.133.130.68])

少なくとも2016年以降は設定されていないようだ。
(2012年半ば~2015年末まではメールが来なかった)

まともに設定できる人がいないんですかねぇ・・・

まぁ、2018/08/09現在掲載されている開発スタッフの求人内容がアレですから、まぁ・・・

応募条件
・RDBMSを利用したシステム開発経験がある方。
とくにMySQLおよびPHPの経験者を歓迎します。
・コミュニケーション能力がある方、25歳くらいまでの方を歓迎します。
<<<総合旅行業務取扱管理者優遇>>>

(25歳まででこれらの技能が身につけられているってなんだろ?)


2018/08/21追記

8/14送信のDMでは、そのままでした
8/21送信のDMではきちんと名前解決がされるようになっていました。

-bash-4.2$ nslookup 211.133.130.68
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
68.130.133.211.in-addr.arpa     canonical name = 68.64/26.130.133.211.in-addr.arpa.
68.64/26.130.133.211.in-addr.arpa       name = sitsmtp.bestrsv.com.

Authoritative answers can be found from:

-bash-4.2$ nslookup sitsmtp.bestrsv.com.
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   sitsmtp.bestrsv.com
Address: 211.133.130.68

-bash-4.2$