久々の備忘録。

 

DNSのMXレコードは複数行書く事が出来る。
その時、メールサーバーの優先順に"優先度(preference)"の値を0〜65535の範囲で設定する。
優先度は優先順位が高い方が数値が小さく、優先順位が低くなるほど数値が大きくなる。

 

例1)
hogehoge.com. 3600 IN MX 10 mx1.hogehoge.com.
hogehoge.com. 3600 IN MX 20 mx2.hogehoge.com.


上記のように多くのWebサイトで優先度を10,20,30…って例をあげてるけど、別に"10から初めて10飛びにしろ"というルールなんて無いので0,1,2…でも、3,6,9…でも、何でも良い。
とにかく、0〜65535の範囲内で、高優先のメールサーバーを小さな数値、低優先のメールサーバーを上位より大きな数値、というルールで記述しておけばいい。

この辺はググればすぐ出てくる。

で、ここからが今回の備忘録のキモ。

複数行書いたときの挙動なんだけど、これから書く事を解説してくれてるWebサイトが殆ど無くて(自分は見つけられなかった)、贔屓にしてるベンダーのSEに教えてもらって初めて知った。

まぁ、プロは知ってて当然なんだろうけど。

最初(優先度最高)のメールサーバーで(アカウント不明とか)何らかの理由で配信不能通知が送信側に戻って来たら、次の優先度のメールサーバーへ再送信される…ような動作はしない
最初(優先度最高)のメールサーバーでエラーとなった時点で、メール送信は終了
次の優先度のメールサーバーへ再送信されるのは、上位のメールサーバーが障害とかで「返事が無い。ただの屍のようだ」状態だった時だけ。

つまり、MXレコードの優先順位で受け取るメールサーバーの使い分けを制御しようとするのは間違い。

 

例2)
 mx1.hogehoge.com 側のみ、"taro@hogehoge.com"と言うメールアドレスがある。
 mx2.hogehoge.com 側のみ、"hanako@hogehoge.com"と言うメールアドレスがある。

 

(例1)のようにMXレコードを設定していて、(例2)のようにメールアドレスが作られているとき、"hanako@hogehoge.com"宛にメールを送ったら、mx1.hogehoge.comが先に受け取って、mx1内にhanakoが居ないと通知を受けた送信側は、MXレコードで次の優先度となっているmx2.hogehoge.comに再送する。
mx2にはhanakoが居るので、mx2.hogehoge.comが無事受信する…という挙動はしない
 

実際は、"hanako@hogehoge.com"宛にメールを送ったら、mx1.hogehoge.comが先に受け取って、"そんな奴は知らん。"と送信側に通知。メール送信者はエラーメールを受け取って終了。

メールサーバーを並行運用したいときは、高優先度のメールサーバーで一度受信して、別のメールサーバーへ転送する。

…という事をするそうだ。

 

自分はこれを勘違いしていた。

DNSに詳しい知り合いも居ないから誰にも相談できず、ネット調べまくってもこれを解説してくれてる人も居ない。

何度もMXレコードを書き換えてテストメールを送ってはエラーメールをもらう。

を繰り返して数週間悩んでた。

 

○○社の××さん、契約の業務外なのに教えてくれて、ありがとう!!

LINEのChromeブラウザー拡張機能版が6月にアップデートするんだとか。


"過去2週間分のトークしか表示されない"とかタダの機能低下なのに"安定性"とかテキトーな言い訳してるもんだから、コイツら何言ってるんだか…とか思っていたらコレ。

 

真っ白。

 

ウィンドウだけ表示されて、その中央で砂時計(昔の言い方)が回ってるだけの画面を永久に見せ付けられるだけ。

アップデート後らしき物は"2週間分のトークのみ"どころか、まともに起動すらしませんでしたって言う結末。

遅くとも2023.6.12にはこんな状態。

 

Ubuntu MATEとの相性が悪いのかと思って、他にWindowsやChromebookで試したけど、どのChromeブラウザー拡張機能版でも同じ不具合が発生しているので、OSは関係ないらしい。

まぁ、"Chromeブラウザー拡張機能版"を名乗るのだから、ChromeブラウザーであればOS関係無しに正常動作して当然なのだが。

そして、androidアプリ版は正常に動作しているように見えるので、LINEに障害が発生している訳でも無さそうだ。


…中の人たち、デバックしてないだろ。徹夜+休日返上で改修してください。

正直なところLINEなんて使いたくないのに、友達がLINEを連絡手段にする事を強く要求するもんだから使ってるんだからさ…。

 

# 追記

LINEの中に人に対して大変申し訳ない。この現象、俺がChromeブラウザーに施した設定が原因でした。

・WebサイトにJavaScriptの実行を許可しない。

・WebサイトにCookieの保存を許可しない。

この2つが、Webサイトだけでなく拡張機能にも影響していたらしい。

ChromeブラウザーのLINE拡張機能を使うときだけ、この2項目の設定を"許可する"に変更すると、正常に動作します。

最近、通勤時に思うんだけどさ…ここ数年、電車の運転手の運転がヘタクソになってない?

JR ,東京メトロ ,私鉄、それぞれ使うけど、どの鉄道会社でも全体的にヘタクソ。

 

・基本的に急加速、急減速で揺れが酷い。

・分岐/合流地点でも構わず通過で揺れが酷い。

・カーブも構わず通過で揺れが酷い。

 

特にJRなんて数年前まではカーブとか分岐/合流みたいな揺れそうな場所では車内アナウンスした上で減速して揺れを最小限に抑えて通過していたのに、最近では減速無しで通過するから揺れまくり。

他の鉄道会社は前からそんな気を使う運転じゃなかったけど。

 

駅前後での加減速も前はもっと緩やかだったと思うんだが、ロケットみたいに発進するし。

減速時は衝突事故でも起こしたのか?ってくらい急減速だし。

 

なんか、そういう所に気を使えないレベルで運行スケジュールに無理でもあるのかね?

 

それとも、俺の体力が落ちて多少の揺れでも大きく感じるようになったか?

…んなわけ無いか。

Rakuten Miniを入手してからコンビニでの買い物は基本的に"楽天Pay"を使うようになった。

楽天はイマイチ信用できないんだけど、中国(Alipay)の姿が見え隠れするpaypayよりはマシかな〜ってね。

例の騒動で楽天モバイルからDoCoMo系キャリアに移住した後も楽天Payだけは続けてる。

 

スマホ決済を初める以前はSuica決済派だったんだけど、チャージの上限が¥20kなのでマメなチャージが必要だし、大きな買い物ができないのも欠点で、最近はSuica払いは回数が減り気味。

JR東日本がSuicaをスマホ決済に対応させたりして、もっとうまくSuicaを活用していれば国内最大勢力の電子マネーになれたものを…。

 

まぁ、そんな訳で、出勤日は昼飯をコンビニに買いに行くわけなんだが…。

東京のど真ん中だと言うのに、DoCoMoが悪いのか、楽天が悪いのか…楽天のサーバーと通信がうまくできなくて"楽天Pay"での決済ができねぇ。

 

休憩時間の通信量にDoCoMo回線が追いつかないのか、楽天のサーバーがリクエストをさばき切れないのか…。

ユーザーとしてはどっちが原因かなんて関係ないので、両社に言いたい。

 

どっちが悪いのか知らんが、両方とも設備強化してこの状況をどうにかしろよ。

 

なんでレジに渋滞作って店員や他の客に迷惑かけて、バーコードが降ってくるのを何分も待たなきゃならんのだ?

混雑時のスムーズさはSuicaの頃のほうが256倍マシだったぞ。

家のカギが「サービス終了」で物議 その後の対応は? スマートロックのQrioに聞く
https://www.itmedia.co.jp/news/articles/2305/17/news113_2.html

カギだとか家電だとか、下手したら20年以上も使い続けるのにスマホアプリ前提なものなんて買うなよ。
スマホ経由で家の外から制御できる家電だとかスマートハウスだとか…何十年後もその時点の最新スマホ向けにアプリ開発し続けてくれるのか?って。
そう考えたら、メーカーがアプリ開発を放棄した時点で使えなくなる設備・家電なんて怖くて買えないだろ普通。
チョット考えたらリスクしか無いって気づくと思うんだけどな…。

そういうわけで、俺様は「スマホでの制御はあくまでオマケ」程度にとどまっていて、本体もしくは付属のリモコンで機器の機能に100%アクセス可能な手段があるモノしか買う気はない。

あと、IOT家電だけじゃなくて電子書籍やストリーミングも事業者の都合で突然サービス終了するから気をつけろよな。
ある日突然、購入した書籍や動画(アニメ・映画等)が見られなくなるって事になるぞ。