(IT) AWSでメールサーバー立てててspamhaus.org使ってると受け取ったメールを全部SPAM扱いされる

もう、メール送信サーバーを自前で運用するなんて、面倒くさいだけで何のメリットもないけど、意地と趣味で続けていたりする。合計6ドメイン、3サーバーでメールサーバーの運用をしている。全部AWS上のpostfixだ。
今日の昼頃、そのうちの一つのメールサーバーで運用しているメーリングリリストへ送信できないよーというメッセージを頂いた。エラーの内容がわからなかったのと受け取ったのが出先だったので、エラーメール転送してくださいとだけ返信して、帰宅後に対応を開始した。
とりあえず、サーバーにログインしてログをみると、確かにエラーになっている。

Nov 3 11:04:39 ip-10-0-1-97 postfix/smtpd[23376]: NOQUEUE: reject: RCPT from 送信元サーバー[IPアドレス]: 554 5.7.1 Service unavailable; Client host [IPアドレス] blocked using zen.spamhaus.org; Error: open resolver; https://www.spamhaus.org/returnc/pub/[AWSのパブリックIPアドレス]; from=<送信元アドレス> to=<送信先アドレス> proto=ESMTP helo=<送信元サーバー名>

spamhausとは、無料のブラックリスト判定サービス。サーバーの設定で「spamhausがSPAMと判定しているサーバーから来たメールは問答無用で拒否する」という設定ができるもの。
最初あんまりちゃんと読まないで、自分のサーバーがブラックリスト登録されたんだと思いこんで、解除依頼すればいいんだろうとたかをくくっていた。そう、なぜかブラックリストに追加されて解除依頼は過去にも経験があったからだ。
spamhaus.orgのブラックリスト確認ページへ行って、自分のメールサーバーのIPアドレスやドメインを入れても問題ないと出る。

なんでだ?
ログをもう一度よく見てみると、SPAM判定されているのは送信者側のサーバーのようだし、リンクされているのはAWSのRoute53(DNS)のIPアドレスのブロック確認ページだ。天下のGmail様から来たメールも見事におはじきになっておられる。どういうこったー?
こういう時はtwitter検索で同じ症状の人を探すのが近道。というわけで、見事に原因にたどり着けた。
9月22日に
AWSから無料でspamhaus使ってるメールサーバーには全部SPAMって答えるよ、さもなければ有料サービスにお入りなさい」と書かれた告知がリリースされているを発見。君か。10月18日から順次適用とな。オレが管理している3サーバーでは、11/1適用が1台、11/3適用が1台、残る1台は未適用という感じだったが、これから順次適用されていくと思うので、該当する管理者は対応を急いだ方がいい。
具体的な対応としては、/etc/postfix/main.cfに書かれているこのエントリーの「eject_rbl_client sbl.spamhaus.org」という部分を削除し、適切なspamチェッカーを設定すればOK。ようするにspamhausを使わなくすること。

smtpd_client_restrictions = (もろもろの許可設定),reject_rbl_client sbl.spamhaus.org,

念のためpostifixやその他のモジュール(DKIMとかdovecotとか)を再起動して復旧となる。
早く気がつけてよかった。死活監視では気が付けない問題なので、利用者からの問い合わせじゃないと気が付けない。
同じ症状で困っている人に向けてblogにしておいた。

(IT) jcomのメールサーバーの行儀が悪い

shirao.netというドメインを20年くらい前に取得して、主にメールでつかっている。
メールサーバーも最初は当時の所属会社にひっそり置いたSunのマシンにqmailを入れて稼働を開始し、その後自宅のSun Ultra10で稼働させていたが、震災の計画停電のタイミングでawsへ移行した。いったんOCNのCloud-nに浮気をしたものの、USリージョン閉鎖に伴い再度awsに戻ってpostfix化したりして。業界の人ならわかると思うけど、自分でメールサーバーを運用するというのはもう、無駄でしかない。
メールを使うだけならGmailでええやんけ、が正解。自分のドメインも持ち込めるし。
自分でメールサーバーを運用していると、攻撃パターンとか迷惑メールのトレンドを肌で感じることができ、少なからずシゴトに活かせるので、面倒だが、好きでやってる感じかな。
実家の両親にも最初からこのドメインのアカウントを使わせていて、メーラーはOutlookを触らせず、最初はAl-Mail、最近ではThnderbirdを使わせている。

ここ一週間くらい、実家の母(84)から俺のアカウントにメールが届かないという事象が発生していた。

同じドメインで同じサーバーを使っている俺も父も何事もなく送受信できているにもかかわらず、だ。
ログを見てみると、こんな感じでrejectしてた。

予想されるストーリーはこんな感じ。
(1)Thunderbirdのアップデートか何かでshirao.netドメインのSMTPサーバーの設定が飛ぶ
(2)その後の送信時に、回線のグローバルIPからJCOM回線と想定され、SMTPサーバーにJCOMのデフォルトが設定される
(3)母から俺あてのメールはshirao.netの中で完結するのに、なぜかjcomのサーバーらしきサーバーから飛んで来る
(4)そのjcomらしきサーバーはomta0014.jcom.zaq.ne.jpという名前でくる。(0014の数字の部分はその時々で違う)
(5)omta????.jcom.zaq.ne.jpというサーバーは正引きでIPアドレスを引けない
(6)ホコリ高き(笑)我がサーバーは正引きできないサーバーからのメールを受け取らない
(7)親子の断絶が生まれる
(8)余談だが、母のお友達のjcomユーザーのメールもrejectしてるが、全部jcomが悪いからね

俺のGmailのアカウントだとメールが届くので、それを使って「ThunderbirdのSMTPサーバーの設定を確認してくれ」と伝えたが、結局どこをどう見ればいいのかわからんと言われ、俺もThundebirdユーザーじゃないので、見ないとわからんということで、クイックアシストすることに。

普通の人なら、スタート>Windowsアクセサリ>クイックアシスト、と言えば、2秒で行けると思うのだが、84歳は一筋縄ではいかない。スタートメニューがなんだ酷いことになってるらしく、Windowsアクセサリに到達できない。作戦変更して「スタートで右ボタン押して検索でkuikkuと打つ」を電話で128回叫んでようやくクイックアシストの「支援を受ける」ボタンに到達。ここまで30分。
クイックアシストで母PCの中をみたら、ThnderbirdのSMTPサーバーはやはり、jcomのデフォルトに変わっていたので、shirao.netの設定に変更。パスワードを設定するところがなかったんだが、テスト送信時に認証のパスワードを聞かれ、無事に設定終了。母PCから俺のアカウントへのメールが開通した。クイックアシストで入ったら10分で解決。昔は、千葉県北部まで足を運んでたが、このクイックアシストは便利だし、感染防止にも役立つな、これ。それにしても年寄りはなぜスタートメニューが酷いことになるんだろうか。確かに酷かったけど、そっとクイックアシストを閉じたなど。

とはいえ、正引きできないサーバーでメール送信してくるjcomのサーバー、ダメだと思うぞ。きっと、届いてないメールたくさんあると思うんだが、大手プロバイダだし、確信犯ってことなのかしら。設計間違えちゃったのかしら。

(IT) お世話になります

「お世話になります」:これから取引をするかもしれない会社へのメールの書き出しの定型句
「お世話になっております」:既に取引のある取引先へのメールの書き出しの定型句

という違いがあると指摘され、愕然としている55歳(告白)。
主に接客業などのサービス業においては常識らしく、入社時研修で覚えるべき項目とのこと。
これまで、何の疑いもなく、取引があろうがなかろうが、「お世話になります」しか使ってなかった。みんなどうしてた?
常日頃、メールの件名がどうだ、成増がどうだとえらそうに書いてるクセに知らなかったことがあったとは誠に恥ずかしい。恥ずかしい記念に晒しておく。ああ恥ずかしい(棒)。

知らなかったくせに反論するわけではないのだが、マナー大好き日本人は勝手にいろいろなルールを設定して魔女狩りをしてきた感じがしないでもない。
社内を宛先としているメールの頭に「お疲れ様です」とつけるのも同じ。それ意味あるか?って思ってるから、つけないようにしてる。
電子メールという後発のコミュニケーションツールにおいて、レガシーなツールである「電話」で運用されていた(なんとなくやってきた)マナーをそのまま適用したのではないかと推察する。「お世話になります」も「お疲れ様です」もそもそもは電話マナーだよねえ?

さらに新しいツールであるLINEやSlackやTeamsでは「お世話になっております」も「お疲れ様です」も書かないのが主流だし、「件名」も存在しない前提でコミュニケーションが成立しているし、それでも電子メールからのシフトは進んでいる。社内だけではなく取引先とも。
だからといって新しいツールでの新しいマナーを古いツールへ適用することは、理屈はどうあれ、社会的信用のためには、避けるほうが無難であることは理解する程度に歳は取ったわけで。

そんなわけで、自分に言い聞かせるために再度書いておく。
「お世話になります」:これから取引をするかもしれない会社へのメールの書き出しの定型句
「お世話になっております」:既に取引のある取引先へのメールの書き出しの定型句

(意訳:土下座する大和田常務の顔で打っていると思ってください)

(IT) Apple関連ドメインのメールがblockされたら

しばらく前に個人で管理しているメールサーバーで発生してたんだけど、今日は会社のメールサーバーでも発生してたので、blogにまとめておく。

Apple社のサービスで使ってるドメイン(me.comとかicloud.com)へのメールが届いてないんだけど、と相談されたら大抵これ、という解決策。
Apple社が自社サービスのメールサーバーの受信フィルタで使っている「proofpoint」というサービスがあって、こいつがある日、急に送信元のIPアドレスに従ってメールをブロックする。その基準はわからない。
ブロックされたらそのIPアドレスのサーバーを使っているドメインからme.comとかicloud.com宛のメールが届かなくなる。
/var/mail/maillog に対応策がログとして残っているので、それを実施。
logの内容はこんな;

Apr 11 06:14:46 smtp_server_name postfix/smtp[ID]: B7E93A****: to=<hogehoge@icloud.com>, relay=mx3.mail.icloud.com[17.172.34.64]:25, delay=2, delays=0.12/0.01/1.3/0.55, dsn=5.7.0, status=bounced (host mx3.mail.icloud.com[17.172.34.64] said: 550 5.7.0 Blocked – see https://support.proofpoint.com/dnsbl-lookup.cgi?ip=IP_ADDRESS (in reply to MAIL FROM command))

(smtp_server_name=自分のSMTPサーバーの名前、 IP_ADDRESS=自分のSMTPサーバーのグローバルIPアドレス)

要は「ブロックしたからなんとかしたけりゃここのサイトにおいで」と。
ログにある https://support.proofpoint.com/dnsbl-lookup.cgi?ip= へ行って自分のSMTPサーバーのグローバルIPアドレスを入力し、「ロボットではありません」にチェックを入れて「LOOKUP IP」ボタンを押す。

ブロックされてない場合はこんなだが、

ブロックされてた場合はこんな。

なので、名前とアドレスと(あれば)会社名を入力し、「ブロック解除お願いします」と日本語でもいいので、入力の上、「SUBMIT」ボタンを押す。審査中はこんな画面だけど、1時間前後でブロックが解除され、最初のブロックされてない画面になる。

一度解除されても、またブロックされているケースもあるので、注意が必要。

(IT) 添付ファイルの解凍パスワード

もともとは、
(1)個人情報を含む添付ファイルはパスワードをかけましょう
(2)別の手段でパスワードは先方に通知しましょう
の2つセットで個人情報保護をしましょう、ということだったはず。
だから、(1)と(2)はできる限り無関係の方がいい。

最近(2)が「別のメールならよくねえ?」という勝手な解釈が横行して、
(1)のメールの全返信で(2)の解凍パスワードが届いたりする。
これは(1)と(2)の関連が明確過ぎるため、悪意があるひとがその関連を
簡単に見破れるため、分けて送る意味はまったくない。
もう一度書いとく。

ま っ た く 意 味 が な い 。

せめて、(2)は全返信ではなく、新規メールとし、宛先を再度確認する
ことによって、(1)で間違った宛先があった場合でもそこに気が付き、
悪意がある人がパスワードの書かれた(2)のメールと(1)のメールの
関連性に気が付きづらい(当然、Subjectも無関係にするし、(2)には
署名もつけない)ようにすることが必要。

よって正しくは、

(1)パスワードをかけた個人情報を含む添付ファイルのあるメールを送付。
(2)新規にメールを作成し、宛先を確認しつつ、件名を変えパスワードを送る

ということ。「正しくは」というより「ややましなのは」が正解だが。

本来はパスワードはメール以外、SMSとかFAXとかで送ってようやく
セキュリティが保たれている状態ではないかと。