Help us understand the problem. What is going on with this article?

思わぬ事故防止!開発時やテスト時に使用するメアドのドメインは example.com に統一しよう

はじめに

Webアプリケーションの開発時やテスト時にはテスト用のユーザーを作成するために適当なメールアドレスとパスワードを登録することが多いと思います。

このとき、みなさんはこんなふうにデタラメなドメインをメアドに使ってないでしょうか?

hoge@hoge.com
test@testmail.com
aaaa@bbb.com
etc...

「こんなデタラメなドメイン、あるわけないやろ!」と思うかもしれませんが、自分はデタラメに付けたつもりでも意外とかなりの高確率でそのドメインは実在します。

実際、上の例で挙げたドメインをブラウザに入力すると、いずれも何かしらページが表示されます。
つまり、そのドメインは現在誰かが使っているということがわかります。

https://hoge.com/
Screen Shot 2020-07-29 at 15.15.59.png

http://testmail.com/
Screen Shot 2020-07-29 at 15.16.59.png

https://www.bbb.org (bbb.com から転送される)
Screen Shot 2020-07-29 at 15.16.39.png

実在するドメインだと何が困るの?

何らかの間違いでその実在するドメインに向けてメールが送信される可能性があります。
特に、ステージング環境などではSMTPの設定がバッチリ整っていて、実際にメールが送信されるリスクが高いかもしれません。

もちろん、メールが送信されても一致するユーザーがいないとそのまま破棄されるかもしれません。
ですが、送信先でどんな処理が行われているのかはこちらではわかりません。

最悪の場合、

  • パスワード変更用のURLが含まれるメールが意図しないドメインに送信される
  • そのメールを受け取った悪意ある第三者がパスワード変更画面経由でステージング環境に侵入する
  • ステージング環境に本番環境とほぼ同等のデータが入っていたため、間接的に情報漏えいインシデントに発展する

・・・みたいなことが起きるかもしれません。

開発環境やテストコード上だったらいいんじゃない?

ローカルマシン上の開発環境やテストコード上では実際にメール送信が行われる可能性は低いかもしれませんが、どんな状況下でも絶対にないとは言い切れません。
ですので、やはり「デタラメなドメインのメアド」を登録するのはなるべく避けた方が良いと思います。

というか、開発環境やテストコード上では事故を防ぐというよりもむしろ、「無意識にデタラメなドメインを付けてしまう」という悪いクセを無くす目的で、僕はコードレビュー時によく指摘しています。

そんなあなたのための example.com

では、どんなドメインを使えばいいのでしょうか?
こういうときにピッタリなのが example.com です。
example.com であれば万一誤送信してしまっても問題が起きません。

example.com, example.net, example.org, example.eduは、ソフトウェアドキュメンテーションやドメイン名の例示のために予約されているセカンドレベルドメインである。
(中略)
これらのドメイン名が予約されていることによって、マニュアルやソフトウェア構成のサンプルでこれらのドメインを使用することが可能である。すなわち、エンドユーザーがサンプルの設定や例示をそのまま使用してしまったとしても、第三者に悪影響が及ばないことが保障されている。

引用元 https://ja.wikipedia.org/wiki/Example.com

上の説明にあるように、example.com に加えて example.net や example.org 、example.edu 使うのもOKです。

というわけで、これからは「開発時に使うデタラメなメールアドレス」は次のように example.com (または example.net や example.org 、example.edu )を使いましょう。

hoge@example.com
test@example.com
aaaa@example.com

自社のドメインもOKかも

example.com 以外で誤送信しても大きな問題に発展しにくそうなのは自社のドメインでしょう。

ですので、「開発時のテストユーザーには example.com か自社のドメインを使う」というルールにしても良いかもしれません。

ただし、「自社のドメインが変わって、旧ドメインが別の第三者に取得された」とか「誤送信が多すぎて、自社ドメインのreputationが低下し、迷惑メールと判定されやすくなってしまった」みたいな問題は発生するかもしれないので、その点はくれぐれもご注意ください。

テストコードの修正例

以下はrspec-railsで書いたテストコードを修正する例です。
心当たりがある人はテストコードを修正しましょう!

 require 'rails_helper'

 RSpec.feature 'ログインとログアウト' do
   background do
     # ユーザを作成する
-    User.create!(email: 'foo@hoge.com', password: '123456')
+    User.create!(email: 'foo@example.com', password: '123456')
   end
   scenario 'ログインする' do
     # トップページを開く
     visit root_path
     # ログインフォームにEmailとパスワードを入力する
-    fill_in 'Email', with: 'foo@hoge.com'
+    fill_in 'Email', with: 'foo@example.com'
     fill_in 'Password', with: '123456'
     # ログインボタンをクリックする
     click_on 'ログイン'
     # ログインに成功したことを検証する
     expect(page).to have_content 'ログインしました'
   end
 end

他にもある例示/実験用ドメイン

(2020.7.30追記)

この記事では僕がふだんよく使っている example.com を取り上げましたが、.test など、予約済みの例示/実験用ドメインは他にもあります。

詳しくは以下のページを参考にしてみてください。

まとめ

@example.com で安全安心なシステム開発を!

jnchito
SIer、社内SEを経て、ソニックガーデンに合流したプログラマ。 「プロを目指す人のためのRuby入門」の著者。 http://gihyo.jp/book/2017/978-4-7741-9397-7 および「Everyday Rails - RSpecによるRailsテスト入門」の翻訳者。 https://leanpub.com/everydayrailsrspec-jp
https://blog.jnito.com/
sonicgarden
「お客様に無駄遣いをさせない受託開発」と「習慣を変えるソフトウェアのサービス」に取り組んでいるソフトウェア企業
http://www.sonicgarden.jp
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした