メールサーバー移管周りでやっとく事メモ

ドメイン移管が伴う場合

  • DNSレコード設定を全部メモ取っとく。
  • whois情報（特に管理者のメールアドレス）が正しいか、現在生きているかの確認と、メールが使われていない場合は現管理者に修正を依頼する
  • 先にドメインを移管しておく。

NSサーバー移管が伴う場合

  • NSレコードのTTLは1日のところが多いので、可能ならば先にNSレコードだけ移管。
    • NSレコード、A, MXレコードなどを同時に変更すると、メールの切り替え時間が3日くらいかかる。あとでMXを変える方が切り替えの待ち時間が少ない。
  • NSレコードのみを変更する場合、MXレコードの設定値に注意。クライアントのドメイン名になっている場合はメールサーバーのドメインに変更する必要がある。設定値は現管理者に問い合わせる必要あり。

メールサーバー変更前のクライアントとの調整項目

  • メールソフトに新しいサーバーに接続するメールアカウントを追加してもらう。
    • Outlookはややこしいのでマニュアルを渡して設定してもらう。
  • マニュアルに記載すること
    • 1アドレスを複数の端末で使うのでない限り、POP3接続とする。（OutlookはIMAPで深刻にバグりやすいので）
    • サーバーからメールを削除するまでの日数を、デフォルトの14日から1～5年くらいに変更する。（パソコンの故障・更新時に過去1～5年分のメールを確認できるようにするため）
    • メールサーバー切り替え後、「既定のアカウント」を新しいものに変更する。
    • メールの自動振り分けを行っている場合、新しいアカウントに届いたメールが古いアカウントのフォルダに振り分けられるため、フォルダの移動あるいは自動振り分け設定のやり直し（古い振り分けを削除し、新しいアカウント配下のフォルダに振り分ける設定を行う）を行う。
    • 3日～2週間ほどは古いアカウントにもメールが届くことを周知。
    • 古いアカウントに届いたメールに返信する場合は、送信元のアカウントを新しいメールアカウントに変更して行うよう周知する。

その他

SPF設定がややこしいことになるため旧メールサーバーからのメール送信も認めるようにするのは避けたい。（ミスったら届かなくなるリスクがあるし）

となると、送信メールサーバーは切り替え後は新サーバーからのみ送るように周知する必要がある。（顧客の負荷は増える問題はある）

DNSやメールサーバーの切り替えはとかく厄介なことになりやすいので、独自ドメインでメールを運用するユーザーや企業は、せめてメールサーバーだけは自社で契約・管理してほしい。

制作会社に丸投げしていると、保守管理を他社に切り替える際全端末でメールソフトの設定を追加したりするコストが発生する。

ドメインの管理移管でやっとくことのメモ

クライアントのウェブサイトリニューアルで、サーバーの引っ越しとドメインの管理も引き継がなきゃいけない場面というのは多い。

クライアントがウェブサイト・メールの管理を全部制作会社に丸投げしてるときに発生する。

まあ、お客さんにしてみれば、「ホームページとかメールとかよく分からないんでうまいことやっといて」ってなるのは分かるんだけど、これをやってしまうと、制作会社は大抵、自社名義で借りたレンタルサーバーにクライアントのドメインを作って、ドメインの管理もサーバーの管理も全部「間借り」状態にしてしまう。

そうすると、リニューアルのついでに他社に保守管理を任せようという時に、サーバーの引っ越しをしなきゃいけない。

この作業が、一歩間違うととんでもないトラブル（メールが使えなくなる、その間に送られたメールが行方不明になるなど）を発生させるのですごく気を使う。

とはいえ避けられない作業ではあるので、トラブルを避けるためのポイントをメモしておく。

事前の確認項目

ドメインをどこで管理しているのか

お名前.comとかなら、ID付け替えだけで済むようにアカウントを準備する。

現在のレンタルサーバーが運営しているものの場合は移管の手続きについて確認する必要がある。

スタードメインなどは転出がクソ面倒（管理移管と解約がセットになっていて一旦解約手続きをすると手戻りできないなど）なので要注意。

現在の各種設定の確認

問題発生時にどうにかできるように移管前の設定を記録しておく

  • DNSレコードの設定
    →使う機会はまずないが、情報のバックアップは大事。
  • whois情報が正しいか確認。特に管理者のメールアドレスなどの連絡先がちゃんと届くものになっているか。
    →管理者移管の手続きにおいて、whoisの管理者にメールで確認する仕様のところがある。現管理者が雑な管理をしていると情報を更新していないなどの理由で使えないメールアドレスであることがあり、移管ができなくなることがある。
    スタードメインは転出手続きを取った瞬間からwhois情報の修正もできなくなるため、解決にとんでもない労力を必要とすることになる。
  • 現在使用中のメールアドレス（アカウント）。
    →新しいメールサーバーに登録するために必要。
  • ウェブサーバー、メールサーバーはどこを使っているか。
    →同一のレンタルサーバーだとアカウントAからアカウントBへのサーバー引っ越しは行えないので注意。Aを解約し、Bを契約するという手続きが必要で、その間、メールもウェブサイトも使えなくなる。

新しいサーバーの情報の確認

  • 外部のドメインベンダーを使えるか？
    →特定のDNSサービスしか使えないところが結構多い。ロリポップはサーバーのDNSかムームードメインしか使えないし、NTT系列も外部のDNSサーバーは使えないところが多い。外部のレジストラを使えるかどうか、契約予定のレンタルサーバーのFAQを確認またはサポートに問い合わせる必要がある。
  • サブドメインでメールアカウントを作れるか？
    →ロリポップはサブドメインでメールアドレスを作ることはできない。
    →特にShopifyは問い合わせフォームの運用に独自ドメインのメールアドレスが必要になる。CNAMEレコードでの接続が要求されるため、サブドメインでメールを作れないと困ることになる。
  • DNSの各レコードの設定
    特にSPFレコード。SPFを設定しないと、Gmailにメールが届かなくなるので注意。今後はDKIM、DMARKも設定できるのが理想。

やっておくこと

  • ドメイン移管を受けるレジストラ/リセラーのアカウント作成。
    →理想はクライアントが契約・管理するアカウントを作成すること。丸投げされているとこちらの名義で管理することもある。
  • サーバーにドメインを登録
  • 新しいメールサーバーにメールを登録
    Xserverの場合は、メールアドレスを登録する際に所有者確認が必要になる。現行のウェブサーバーの公開ルートディレクトリに所定のhtmlファイルを設置するか、webmaster@~またはadmin@~のメールアドレスに対して所有権確認が行われるため、現在の管理者にメールアカウントを登録してもらう必要がある。
  • クライアントのメールソフトに新サーバーに接続するアカウントを追加する。
    →Outlookは同一メールアドレスでのアカウント追加は原則不可で、特殊な方法で追加しないといけない。クライアントに手順書を渡すなどしておく必要がある。
    →Outlookは、アカウント追加時に解決不能なエラーが出やすいので注意。IMAPの方がトラブルが発生しやすい印象。
  • 新しいウェブサーバーにサイトを構築
    →Xserverだと仮アドレスが無いのでhostsを編集して確認しないといけないのが面倒。
    →Wixなどを使う場合はAレコードやCNAMEレコードなどの値をどうするのかチェックしておくこと。
  • 切り替えの計画と手順の作成。

 

保守管理契約してるんならWordPressのセキュリティアップデートくらいやっとけよォ～

色々なしがらみからウェブサイト（WordPress）の保守管理は現在契約中の会社と続けないといけないけど、信頼関係があまりないのか、サイトの修正を頼みたいとの依頼が飛んできた。

 

ちょっとした修正程度のニュアンスで進んでいたのだけど、「こう変えたいんです！」と具体的な話になった途端、内容がリニューアルレベルの話に。

 

おいおい…

 

一応、クライアントには保守契約結んでる会社から管理者権限のアカウントを発行してもらうことできた。

管理画面に入ってみると、いろいろ問題が。

 

まず目についたのが、WordPress本体のバージョンが低い。

とはいえ、チェックしたところメジャーアップデートしていないだけで、マイナーバージョンは最新になっていた。

一番の問題はプラグイン。おそらく保守管理の会社が製作してから一度もアップデートしていない。セキュリティホールも放置。中にはメンテされないまま、セキュリティの事由により公開停止されている。

 

こうなっている理由は2つほど考えられた。

一つは、保守管理を請け負っている会社がサボっている。

もう一つは、テーマが本体のアップデートで不具合を出す可能性が高いこと。

 

管理画面からテーマエディタを開いてコードをチェックしたらまあ、ダメの典型。

トップページはコンテンツを front-page.php にハードコーディング。ここまではまあ許容範囲。ひどいところは固定ページ全部ハードコーディングしてるからね。

このテーマはとりあえず固定ページはまとも。固定ページの投稿画面にコンテンツがある。（とはいえarchive.phpなどに固定ページテンプレート名を付けるなど、WordPressについて分かってない人が作った形跡が見て取れたのだが）

驚いたのが、functions.php にコードが一切無かったこと。style.cssにもテーマ名の情報があるだけでCSSのコードは皆無。

 

あー、このパターンかと。

 

関数やら何やらは、functions.phpではなく、別のファイルに細かく分けておかれているのだろう。PHPプログラマがやりがちなやつ。

WordPress屋ではなく、PHPerが作ったな、と判断できるポイントとして、cssやjs、画像などを /assets/ ディレクトリに入れるってのがある。このテーマもそのパターン。

まあ気持ちは分かる。普通のウェブシステムってそんな作り方するし。慣れたディレクトリ構成を変えるのって気持ち悪いもんね。

 

ただ、これをやられると、管理画面のテーマエディタではテーマの全容が把握できない。

そしてPHPerがWordPressテーマを作るときにやりがちなのが、WordPress関数をほとんど使わないこと。

WordPressはPHPで動くから、それでも最初はちゃんと動くんですよ。最初はね。

 

ただ、こういうテーマは往々にしてWordPressのアップデートやPHPのアップデートについていけない。エラーが出る。ひどいときはサイトが全く表示されなくなる。廃止されたPHP関数のせいで処理が止まるから。

 

まあ、そんな状態では、WordPress本体のアップデートはできない。プラグインは最新版のWordPressに追従するから、プラグインだけ最新版にしてしまうと、アップデートしていないWordPressで正常に動かない可能性がある。だからプラグインもアップデートしない。

 

こういう、アップデートできないテーマって、制作会社が独自に作ったテーマや、有料のテーマでよくみられる。

 

WordPressのアップデートを阻害するテーマは時限爆弾でしかない。

お金をもらって、将来サイバー攻撃による損害を発生させるものを納品するってのはほとんど犯罪じゃないかとすら思う。

 

で、そういうサイトを納品し、そして保守管理契約を結んでおきながらセキュリティホールを放置している業者さんよ。恥を知れ。

 

独自のテーマでやるのなら、せめてアップデートについていけるよう、つくりはシンプルに、そして可能な限りWordPress関数を使って、ガイドラインに沿った標準的なやり方で作るべき。

そうすればアップデートのたびにテストする必要性はほとんどない。本体もプラグインも基本的に自動更新にすることができるから月額が安くてもペイするんだよ。

この分野でひとかどの人物になりたいのなら、"スタバでマック"はやめなさい。

どうせなら。平日の昼間っからスタバでMac。

というコピーから始まる広告が炎上しております。

何故炎上したのかというと、それは社会人としてあまりにも非常識な行為だからです。

 

問題の広告の最後はこう締められています。

どうせなら。わたしたちと。

かっこつけちゃって、生きてみませんか？

うーん、実に恥ずかしい。

かっこつけでスタバで仕事するような人に、仕事のできる人は一人もいません。「私は不特定多数がいるような場所で仕事なんかしちゃうプロ意識の欠落した人物です」という看板を首から下げているようなものです。

 

いや、それをかっこいいと思う気持ちはよくわかります。私も昔は憧れました。全然仕事が無かった頃ですけど。スタバじゃないけど無料Wi-Fiがあるカフェでポートフォリオ作ったりね。だからそれにあこがれるあなた方の気持ちはよく分かる。だから言うけど、

 

さっさと目を覚ませ。

 

やってみれば分かるけど、はっきり言ってカフェなんてパソコン使って仕事する環境じゃないんですよ。画面は1枚しかないし、後ろから丸見えだし、トイレに行くときにはガサゴソとパソコンを片付けて、荷物持っていくわけですし。

なんなら飲み物ぶっかけてマシンをお陀仏させるリスクもあるわけですし。

 

根本的な問題として、仕事のほとんどは気密性の高い情報です。顧客が絡んでいるような仕事を、後ろから画面を覗き見られるような環境でするのは、控えめに言って狂ってます。意識低すぎ。

酷い場合は、そこでZOOM繋いで会議なんかする人もいるわけですよ。お前なに公の場でイヤホンもせずに顧客と会議してるんですか正気ですかと。

 

要するに、「スタバでマック開いてイケてる仕事♪」なんてやってる人は、例外なくプロ意識が欠落しているダメ人間なんですよ。

 

カフェでコーヒーを飲みながらおしゃれなMacを開いて優雅にお仕事、というのは格好よく見えるかもしれませんが、そこにあるのはただの自己陶酔と自己満足。

 

「カフェという場所とMacというおしゃれアイテムで誰でも簡単♪　イケてる私をお手軽演出♪　でも機密も守れない三流未満のダメ仕事やってます♪」

 

それってどこがかっこいいの？　恥ずかしくない？　一流の仕事をするのが格好いいんじゃないの？

 

仕事はファッションじゃないんです。

 

お金をもらってモノやサービスを提供する以上、顧客の機密よりも自分の格好良さを優先するような人間にろくな仕事なんてできやしません。

あれは外見ばかり気にして中身がスッカラカンの恥ずかしい人物のやることだということに早く気づいてください。

 

本物のかっこよさを、手に入れましょう。

楽な道ではないけど、「スタバでマック」をやめるのがその第一歩です。

ロリポップで、外部ドメインのA,MX,TXTレコードを設定する方法

「お名前.comなどでドメインを取得、サイトはロリポップで運用したい。」

という場合、単純な運用であれば、ネームサーバーをロリポップに向けてしまえばいいのだが、それをやるとサブドメインを別のサーバー（ECサイトなどね）で使いたい場合に使用不能に陥る。

そこでAレコード、MXレコードなどを調べようとすると、公式の情報が全く見つからないので、電話サポートに確認することになる。（なお、ロリポのチャットサポートは的外れなヘルプページへのリンクを出すばかりで役立たず、メールサポートと同じで、人間によるサポートを得るには数日待たされることになる）

 

電話サポートで確認したところ、非公式の方法を教えてもらったのでここにメモをしておく。

 

1) ロリポの管理画面「基本情報」のサイトアドレスから、契約時に与えられたサイトアドレスのドメイン（サイトアドレスから http:// と、末端の / を除いたもの）をコピー。

 

2) whoisなどでDNS情報を調べる。分かりやすいのは禅ドメインのDNS検索

https://xendomains.com/Dns

ここに出力されたレコードがDNSの設定値となる。

 

※MXレコードを設定する際は、TXTレコードも設定する。（spfを設定しないとスパム扱いされることがあるため）

 

注意点として、ロリポのAレコードはメンテナンスで変わることがあるため、サーバーメンテナンス情報には神経をとがらせておく必要がある。サイトが表示されなくなったら速やかに上記の作業をもう一度やる必要がある。

 

結論：ロリポップはちょっと複雑な運用には向かない。あるいは、ロリポを契約する場合、ドメインはムームードメインを使う。

Shopifyテーマ編集を始める際のコマンドのメモ

※Windows環境の手順。

  1. PowerShellを立ち上げる。
  2. cd テーマを入れいているディレクトリ
  3. shopify login [--store ストア名]
  4. shopify theme pull　
  5. →プルするテーマの番号を入力
  6. ローカル環境を立ち上げ、編集をリアルタイムで確認するには、shopify theme serve
  7. ローカル環境を閉じるにはCtrlキー+c。閉じないと次のプッシュができない。
  8. shopify theme push
  9. →プッシュするするテーマの番号を入力。再確認でYesを選択

Shopify Dawnテーマ　ウェブフォントの適用

記事執筆時点で、Shopify にはNoto serifはあるが、Noto sans はサポートしていないため、これを導入することにした。手順を以下にメモする。

1. /assets　フォルダにフォントファイルを入れる

2. /config/settings_schema.jsonを編集

 {
        "type": "font_picker",
        "id": "type_body_font",
        "default": "assistant_n4",
        "label": "t:settings_schema.typography.settings.type_body_font.label",
        "info": "t:settings_schema.typography.settings.type_body_font.info"
      },

の下に以下を追記

{
        "type": "textarea",
        "id": "type_body_jp_font",
        "label": "日本語フォント設定",
        "info": "この欄に入力されたfont-familyをフォント設定に追加します。"
      },

3. /layout/theme.liquid を編集。CSSの :root{~~ の前にウェブフォントを読み込ませる。


      @font-face {
          font-family: "noto-sans";
          src: url("{{ 'NotoSansJP-Regular-Subset.woff2' | asset_url }}") format("woff2");
          font-weight: normal;
      }
      @font-face {
          font-family: "noto-sans";
          src: url("{{ 'NotoSansJP-Bold-Subset.woff2' | asset_url }}") format("woff2");
          font-weight: bold;
      }

さらに、:root {～～}　内の

--font-body-family: {{ settings.type_body_font.family }},{{ settings.type_body_font.fallback_families }};

と

--font-heading-family: {{ settings.type_header_font.family }}, {{ settings.type_header_font.fallback_families }};

に{%- unless settings.type_body_jp_font ==blank -%} {{ settings.type_body_jp_font }}, {%- endunless -%}を追加。以下のようにする


        --font-body-family: {{ settings.type_body_font.family }}, {%- unless settings.type_body_jp_font ==blank -%} {{ settings.type_body_jp_font }}, {%- endunless -%} {{ settings.type_body_font.fallback_families }};
        
        --font-heading-family: {{ settings.type_header_font.family }}, {%- unless settings.type_body_jp_font ==blank -%} {{ settings.type_body_jp_font }}, {%- endunless -%} {{ settings.type_header_font.fallback_families }};

管理画面の 「テーマ設定」＞「タイポグラフィ」に新たに作られた「日本語フォント設定」に

"noto-sans", "Hiragino Kaku Gothic ProN", "Hiragino Sans", "BIZ UDPGothic", Meiryo, sans-serif

を追加。

ただ、これでうまく動いている感じは全くないので、CSSの:root{~~}に、

font-family: "noto-sans", "Hiragino Kaku Gothic ProN", "Hiragino Sans", "BIZ UDPGothic", Meiryo, sans-serif;

の記述を書く。

 

参考文献

https://shopify.dev/docs/themes/architecture/settings/fonts#custom-fonts

なお、上記の本は執筆社の直販サイトから購入すると、PDFの電子本も一緒に入手できる。

Hello Shopify Themes Shopifyテーマ開発ガイド｜non-standard world株式会社