「拒否」タグアーカイブ

(IT) ソフトバンク回線のiPhoneにSMSが届かない

投稿日時: 投稿者:
返信

結果から先に書いておくと、自分で端末(iPhone)内の設定でソフトバンクの汎用SMSを送信しているゲートウエイの番号(21053)をブロックしていた、という話。

最近ネット上のいろいろなサービスがセキュリティを固くする方向で、多要素認証の一手段としてSMS認証を採用することが多くなった。ログイン時にパスワードだけではなく、SMSで届く何桁かの数字を入力することでようやくログインできるような仕組みを採用することが多いようだ。
なので、SMSが届かないととっても困ったことになる。
ブラウザで目的のサービスのサイトが見えたり、アプリは開くものの、SMS認証ができなければ登録情報の変更や、生体認証への切り替えなど重要な操作ができなくなる。

で、iPhoneでSMSが来ないサービスがいくつか発生してちょっとだけ困っていた。具体的にはカーシェアのTimesとか、美容院の予約で使っていたリクルートのHotPepaerなど。困った。

考えられる原因は３つ。サービス側、ソフトバンク側、端末(iPhone)側の３つ。
このうち、サービス側が原因の場合というのは、一時的な障害しか考えられず、時間をおいてトライすれば回復するはずなのだが、数カ月にわたって回復しないので、ここが原因ということはない。

というわけで、ソフトバンク側の設定を疑った。いろんなサービスのFAQでも「SMSが届かない場合はキャリアの設定を疑ってこのあたりを確認するといいよ、ちなみにソフトバンクはここね」と書いてある設定を確認はするものの、フィルターはすべて無効になっていてどうも、ここも原因ではなさそう。

ただ、設定画面の日本語が微妙なので、何かの設定が悪さしているのかなあ、くらいにしか思ってなかった。というか、致命的に困っていなかったので、真剣にトラブルシューティングをしていなかった。
端末側のフィルターはこの項目ぐらいだろうと思ってここもあまり真剣に調べなかった。

Screenshot

しかし、iPhoneの全面ガラスがかけてしまったので、Apple Care発動させてガラス交換をした時に端末のリセットが必要となったため、修理時にOKした。iCloudのバックアップから戻せばOKだろうと思っていた。
しかし端末がリセットされると、生体認証(iPhone SE3 の場合はTouchID)もリセットされるので、指紋認証で登録していたサービスやアプリが全部再設定になる。
端末リセットから数日後にカーシェアを予約してあって、Timesアプリで指紋認証でクルマのロックを解除しようとしたら、指紋認証がリセットされていて、クルマの前で立ち往生するという事態が発生した。解錠用のカードは持っていなかったからだ。SMSが届けばその場で指紋でのロック解除設定ができたのだが、SMSが届かず再設定ができず、サポートセンターに電話してロック解除してもらうというIT爺としては敗北感を味わってしまった。さすがに本気でトラブルシュートしようと思い立った。

某銀行の指紋認証もリセットされていたので、これを再設定しようとした時のSMSは届くので、これはどうやらキャリア側の設定ではなく、端末側の設定に違いないと気がついた。
そう言えば、iPhoneに来たSMSはiMacにもiCloud経由で同期して届いていたので、iMac側で横取りしているか、何か間違った設定をしてしまったのかと思ってiMacのメッセージアプリの設定を見直してみたら、「ブロック」なる設定を発見した。

「あれ？オレ、こんなにSMSをブロックしてたか？」と思うほどの数の番号やアドレスが表示されて驚いたのだが、この中にTimesのサポートの人が許可設定するなこの番号ですと言っていた「21053」を発見した。これかー！
この番号をブロックリストから削除したら、それまで来なかったSMSが届くようになった。
SMSを拒否していたのは自分自身だった。

これがなぜ起きたのかを考えてみると、ソフトバンク回線のiPhoneのメッセージアプリには電話番号で届くSMSと@softbank.ne.jpドメイン宛に来るキャリアメールが一緒くたに並ぶ。言い換えるとSMSとキャリアメール宛の迷惑メールが混在して表示されることになる。で、このメッセージアプリ、左スワイプでメッセージの削除ができるのだが、この時、「削除してブロック」という親切機能がある。

Screenshot


キャリアメール宛に来た迷惑メールをスワイプで連続削除している時にこの21053から来ていたSMSも「削除してブロック」してしまったようだ。この番号21053はソフトバンクの汎用SMSゲートウエイらしく、多くの会社のサービスがこの番号を発信者番号として送信してくるらしい。なので、この番号をブロックしてしまうと、来なくなってしまうSMSは1社のものだけではないわけだ。メガバンクなど自前ゲートウエイで送ってくるサービスを除いて21053をブロックすると来なくなるSMSはたくさんある。

このブロックはiPhone側では確認できないのかと思ったら確認できた。
設定＞アプリ＞メッセージ＞着信拒否した連絡先
ここにあった(iOS26)。これは、電話アプリから見られるリストと同等だ。電話アプリとメッセージアプリは同じ拒否リストを使っているということなのね。

Screenshot

というわけで、電話もメール(メッセージ)も気軽にブロックするようにしてきたが、SMSに関連するブロックに関しては今後は少し慎重にやらないといけないと思った次第。

(IT) 今どきの若者は未経験でも1ヶ月の研修でクラウドを駆使できる(驚)

投稿日時: 投稿者:
返信

妻の元教え子だった女性25歳。
大手飲食チェーンのお店で店長までやって働いてたけど、IT業界へのJOBチェンジを決意してハロワの若者の就業支援サービスを受けて晴れてこの4月から「未経験歓迎・研修3ヶ月」なる会社へ正社員で就職。いやあ、適当に研修してあんましわかってないうちに辛い現場に押し込まれたりしたら可哀想だなあ、とかぼんやり思ってた。言い換えると基礎知識なしで業界違いの人を研修するなら3ヶ月って短いよな、と思ってたわけ。
ところが。GW中に他の元教え子達とウチに遊びに来て、ちょっとしゃべったら「AWSのVPCにWebサーバーたてて、イメージ取って2つ目のサーバー立ててから元のサーバーにTeratermでSSHしようとしたら、『接続が拒否されました』って言われて接続できなくなってタイムアップしたところが私のGW前の成果です(キリっ)」と淀みなく話されてびっくりした。
デジタルネイティブというか、そもそもクラウドとかWebサーバーとかアプリとか普通に使ってて、なんとなく技術的背景も想像ついてる子は専門的な学習が最小限でもそこそこの戦力に仕上げるのに時間いらなくなったのかあ、とびっくりした。オレが新卒の研修やってた頃の若い人達って若いとはいえスマホ出始めの頃だったし、クラウドもなかったことから考えると、背景がだいぶ違うんだなあ、と本当に驚いた。
併せて読みたい：「(IT) 無限Wifi」(2014年の記事です)

(IT) 自ドメインの設定が参加しているメーリングリストの配信に影響があった話

投稿日時: 投稿者:
返信

趣味のランニングのチームのメーリングリストのサーバーの運営をしている。
そんなもん、Googleでも何でも適当な無料サービスがあるだろ、なんて指摘は全然承知はしているんだけど、Webサーバー用にドメインもあるので、だったらチームのドメインでPostfix運用してMLエンジンもいれてメーリングリスト運用しちゃおう、ってことになっちゃって。
広告が入るのがイヤ、ってのもメンバーの皆さんにあったりとか、過去の経緯もあったりで。

前置きここまで。で、このメーリングリストのサーバーからのメールの一部をドコモ様が拒否していることが発覚。
レジェンドMさんから「XXXX番とYYYY番が届いてねえぞ！」と怒りのLINEが。あ、MLなんて止めてLINEグループにしちまえ、なんてご指摘もご遠慮くださいね笑
調べてみたら、3月中旬くらいから送信者がオレの場合にだけ、ドコモ宛とicloud宛のメールが先方のサーバーの拒否(Usesr Unknown)でバウンスしてた。同じメーリングリストで他の人が送信した場合は同じ宛先でもドコモのサーバーは受け取ってくれているのに。
まあ、メーリングリストのメールって、本当の送信者のドメインと送信元のサーバーのドメインが違うので、あやしいといえば怪しいのは承知してるんだけど、なんでオレのだけ？
と思って更にログを調べてたら、icloudさんのバウンスのログにヒントがあった。ちなみにドコモのサーバーの拒否ログはこんな

to=<hogehoge@docomo.ne.jp>, relay=mfsmax.docomo.ne.jp[203.138.180.240]:25, delay=1.3, delays=0.09/0.02/0.1/1.1, dsn=5.0.0, status=bounced (host mfsmax.docomo.ne.jp[203.138.180.240] said: 550 Unknown user hogehoge@docomo.ne.jp (in reply to end of DATA command))

「そんな人、知りません(プイっ)」みたいなログしか残らない。
これに対してicloudさんのログはヒント付き。

to=<hogehogehoge@icloud.com>, relay=mx02.mail.icloud.com[17.57.156.30]:25, delay=31, delays=0.1/0/1.9/29, dsn=5.7.1, status=bounced (host mx02.mail.icloud.com[17.57.156.30] said: 554 5.7.1 Your message was rejected due to shirao.net’s DMARC policy. See https://support.apple.com/en-us/HT204137 for info (in reply to end of DATA command))

「なんや、しらんけど、shirao.netのサーバーのDMARCポリシーがそうせえ、書いてるから拒否しとくわー。ちなみにここ参照な」ってことらしい。
ああ、なるほど。shirao.netの中の人が送信してると主張している割に送信元のサーバーが違うドメインだった場合は、拒否してくれ、ってDNSに書いた記憶があるわー。ってことでshirao.netのDNSのTXTレコードを確認。

_dmarc.shirao.net TXT v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@hogehoge.com; ruf=mailto:dmarc@hogehoge.com

これの「p=reject」ってところが「もし違うサーバーからshirao.netを語るメールが来ても信用しないで拒否してちょうだい」って意味。これを「p=none」に書き換えたらドコモ様も受信してくれるようになった。MLのドメインから来ても信頼してみてね、ってこと。
ただ、この設定は一時的にはいいけど、永続的に設定するのは非推奨らしいので、他の設定を調査を継続中。まあでも、とりあえずは解決した。
ドコモやicloudみたいな広義でのISP(Internet Service Provide(死語))は時々メール受信の判定ルールを好きなタイミングで緩めたり厳しくしたりするんで、こういうことがたまに起こるみたい。今回も3月中旬に急にこのDMARCの判定を厳密にするようになったっぽい。同じように困ってる人の助けになりますよう。あ、自分がメールで使ってるドメインのDNS設定いじれる人ってそんなにいないか笑