お客さんから「メールが戻ってくる!なんとかせい!」との電話が。(Oh! my Goodess!!)
Server.appの設定と、手作業で弄っている内容に不一致が出ていることは予想される。だが、Server.appは一画面内での設定を複数のファイルにわたって更新しているようだ。
それがどこだか判らん。
まずはLogを見る。
前回修正した筈の
check_client_access hash:/etc/postfix/reject_client
が間違え。というか、参考にしたサイトのままだった。
check_client_access hash:/Library/Server/Mail/Config/postfix/reject_client
Pathが全く違う。(^_^;;
次がこれ。
|
1 |
Nov 22 10:33:59 macmini.k-in.co.jp postfix/smtpd[3396]: NOQUEUE: reject: RCPT from mail-qk1-f170.google.com[209.85.222.170]: 450 4.7.1 <support@k-in.co.jp>: Recipient address rejected: Service is unavailable; from=<foopa.org@gmail.com> to=<support@k-in.co.jp> proto=ESMTP helo=<mail-qk1-f170.google.com> |
Recipient address rejectedであり、Service is unavailableである。(意味が判らん)
Google先生にお願いする。「受信者のアドレスが拒否されました:サービスを利用できません」………お〜い、一番肝心なサポートちゃん宛のメールが受けられないよ〜(涙)
他にも出てくる。
|
1 |
Nov 22 12:02:05 macmini.k-in.co.jp postfix/trivial-rewrite[6680]: warning: do not list domain k-in.co.jp in BOTH virtual_alias_domains and relay_domains |
これは、virtual_alias_domainsをコメントアウトすることで回避できるらしい。(warning: do not list domain [FQDN] in BOTH virtual_alias_domains and relay_domains参照)
ってことで早速やってみる。
お客さんのメールが届かなかったのは、逆引きに失敗していたからみたいだ。Gmailの場合もそうで、逆引きに失敗する。そしてエラーとなったことで気が付いた。
ってことでwhite listとしてaccessを使おうと、ipとdomainを許可として書き込み、Server.appからMail Serviceを再起動する。
変更前と同じ状況となったため、確認してみるに、なんとaccessが初期化されていた。
同様に
|
1 |
Nov 22 13:20:36 macmini.k-in.co.jp postfix/postfix-script[15522]: warning: not owned by _postfix: /Library/Server/Mail/Data/mta/./guid_device_maps.plist |
これも毎回出てくる。chownで変更しても再起動をかけると戻ってしまう。
前回、作成したreject_clientにGmailからの受け入れをしようとしても無理のようだ。
check_client_access hash:/Library/Server/Mail/Config/postfix/reject_client
hashの場合、ip rangeの指定ができないらしい。この場合はcidrのデータベースを使うそうだ。
check_client_access cidr:/Library/Server/Mail/Config/postfix/access.dir
として、access.dir(accessはすぐに初期化されてしまうため使えない)を以下のように作成してみた。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
# Google 209.85.128.0/17 OK # yahoo.co.jp 182.22.37.00/24 OK # unkown address # UK 159.65.48.0/20 DISCARD # Poland 193.169.255.0/24 DISCARD 193.56.29.0/24 DISCARD # Netherlands 91.199.168.0/24 DISCARD 91.199.168.0/24 DISCARD # Pakistan 203.135.22.0/24 DISCARD # Brazil 177.36.59.0/24 DISCARD 187.111.42.0/24 DISCARD # China 180.160.0.0/13 DISCARD 117.50.160.0/19 DISCARD 119.36.0.0/16 DISCARD |
Googleだけでなく、Yahoo Japanも逆引きできないので、こうなる。
中国・香港等から送られて来るのは、Amazonの成りすまし等のみなので全部捨てることにしている。
unknownは一応通さないようにはしているが、Server.appが時折main.cfを書き換えてしまうため、気が付けば追加することにした。
smtpd_client_restrictionsは順にチェックして、OK、REJECT判定が通ったら終わりらしい。今までは一番下に置いていたcheck_client_accessを前に持ってくる。また、spamチェックサイトは一つで足りるようだ。一番厳しい(らしい)zen.spamhaus.orgを使わせて貰い他は消す。(all.rbl.jp等、既に無くなっているサイトもあった。エラーログを見て知った)
|
1 2 3 4 5 6 7 8 |
smtpd_client_restrictions = permit_mynetworks permit_sasl_authenticated check_client_access cidr:/Library/Server/Mail/Config/postfix/access.dir check_client_access hash:/Library/Server/Mail/Config/postfix/reject_client reject_unknown_client reject_rbl_client zen.spamhaus.org permit |
ここまでしても、greylist.plが先に動いてしまうため、Gmailの受信のチェックには時間がかかる。(向こうのmail serverのどれが再送するか判らない。つまり毎回greylist.plが動く可能性がある)
main.cf等の設定ファイルを書き換えて再起動すると、greylist.plのデータベースが初期化されてしまうからである。そしてログを確認するに、unknownが山ほども来て去っていく。正直見辛くて邪魔である。testとかinfoとかを騙ってloginしてくるのが更に邪魔だ。
ここまでして、まだGmailが受け取れない。つまりお客さんからのメールも受け取れないだろう。
今日は用事があるので、これ以上できない。弱った、困った。


