BIMI 対応したメール配信を実際にやってみたのでやったこと全部詳しく書いてみる

morikawa

プロダクトエンジニアリング部の morikawa です。

今回はトライコーンで行った BIMI 対応メール配信について、やったことをできるだけ具体的にご紹介してみたいと思います。

BIMI については Gmail での対応以後、Apple でも対応するといったニュースが流れるなど環境が整いつつあり、「BIMI とは？」であったり「BIMI 配信はじめました」といった記事も増えてきてだいぶ設定の敷居は下がりつつあります。ただ、BIMI 対応に必要な VMC (認証マーク証明書) の取得手続きでロゴの商標登録が必要だったり、対面 (ビデオ通話可) での認証手続きが必要だったりと、経験がないと見通しづらい作業も多かったため、その手の諸々の事務的作業も含めて詳しい情報があると、今後 BIMI 対応に携わる方のお役に立てるかと思い、今回記事にしてみました。

また BIMI 対応の中で DNS レコードの設定であったり、証明書やブランドロゴの公開といったことが必要ですよ、といった情報は多いのですが、例えばどうやったら良いの？ はあまり見当たらなかったので、一例として AWS Route53、S3 を使ったらこんな感じです、といったことも載せてみました。具体的に何やったら良いかぱっとイメージつかないな、といった方のお助けになれば幸いです。

目次

目次

  1. 目次
    1. BIMI とは
      1. 前提条件
        1. これからやることの関係性
          1. BIMI 対応したメール配信をやってみた
            1. ロゴの商標登録
              1. BIMI用SVG形式ロゴ画像データ作成
                1. DKIM 対応
                  1. DMARC 対応
                    1. VMC 購入手続き
                      1. VMC 発行手続き
                        1. VMC の受領
                          1. VMC とブランドロゴ画像データの公開
                            1. BIMI レコード設定
                              1. BIMI の検証
                                1. BIMI 対応メール配信
                                2. この他に BIMI 導入に必要なこと
                                  1. まとめ

                                    BIMI とは

                                    BIMI はメールがなりすましされていない事をメール受信者に視覚的に伝える仕組みです。
                                    フィッシングやビジネスメール詐欺といった “なりすましメール" 被害を防止するための仕組みとして期待されていて、近年 BIMI を利用できる環境も整ってきました。

                                    BIMI って何？ 何が嬉しいの？ どんな仕組みなの？ 世の中で使われてるの？ といったことが気になった方はまずは以下の記事を参考にしていただければと思います。

                                    前提条件

                                    今回の記事では以下の状況を前提にした説明になっています。この記事を参考にして BIMI 対策を始められる際にはご留意いただければ幸いです。

                                    • ドメインとして autobahn.email を使用
                                    • ブランドロゴは既に存在する
                                    • DMARC チェックには DKIM 認証を使用 (SPF 認証については言及しない)
                                    • DMARC ポリシーには拒否 (p=reject) を使用
                                    • BIMI セレクタはデフォルト値である “default" を使用
                                    • BIMI に必要な VMC はデジサート社より購入
                                    • メール配信には クライゼル (DKIM 配信に対応) を使用
                                    • DNS レコード管理には AWS Route53 を使用
                                    • 証明書やブランドロゴ画像ファイル置き場には AWS S3 を使用
                                    • BIMI の動作検証には Gmail を使用

                                    なお、DNS レコード設定の確認で Linux 系 OS の dig コマンドを使用している例があります。 dig コマンドを実行する環境がない場合にも nslookup(dig)テスト【DNSサーバ接続確認】 のようなサービスもありますので、設定した DNS レコードについてどのような問い合わせ結果が得られるか知りたい場合は利用をご検討ください。

                                    これからやることの関係性

                                    以降でやったことを順番に述べていくのですが、作業の数と種類が多くて、「これ何のためにやってるの？」が分かりにくいかも、と思いましたので、どれを何のためにやっているみたいなことを簡単に図示してみます。頭の整理に役立てば幸いです。

                                    実線矢印の元にある作業が矢印の先にある作業に必要なもの、といった書き方をしています。番号を振っていますが、これが実際に作業を行った順番でもあり、以降で説明する順番でもあります。破線の矢印は少し特殊な意味合いのもので、矢印の先にある作業に対して矢印の元にある作業が必須ではないが、事前に実施しておくことを強く推奨するものであることを意図しています。この節の最後でこのように表現している理由を説明します。

                                    図を見てもらうとイメージが付きやすいかと思いますが、BIMI 対応においてキーになるのは VMC の発行になります。VMC の発行の時点でロゴ画像データの存在と商標登録状況が確認されますし、また DMARC 対応も終えておけば、VMC が発行された後は比較的簡単な作業を済ませれば BIMI の対応は完了します。

                                    ①、② の作業と③、④の作業は平行に進められるものですが、ロゴの商標登録には審査など一定の時間がかかるため先に手掛けています。既にロゴの商標登録は完了している、みたいな状況であれば①～④は作業としては比較的あっさり済み、VMC 発行手続きに進めるかと思います。

                                    「④ DMARC 対応」に ※ マークを付けているのは、状況次第では最も時間がかかる可能性があること、またこの記事ではその点については敢えて言及せずに DMARC の設定作業のみを記しているためです。この点について詳しくは記事末尾の「この他に BIMI 導入に必要なこと」にまとめてありますので、実際に手掛けようとされる際にはご一読頂ければ幸いです。

                                    最後に破線矢印についてですが、まず原理的には VMC 発行にあたって、少なくともデジサートでは DMARC 対応は必須ではありませんでした。ただし、発行にあたってデジサートが用意する事前チェックシートには DMARC 対応の目処を立てる項目があったり、販売代理店からは『認証手続き前に DMARC 設定をご準備ください』といった連絡もあり、VMC 発行前に DMARC 対応を完了することを強く推奨するようなコミュニケーションがありました。これは VMC をせっかく発行しても、 DMARC 対応が済んでいないと BIMI に利用できないためと思われます。VMC には発行から1年の利用期限がついており、VMC 発行後に DMARC 対応でもたついていると、どんどん実際の利用期間が減ってしまいます。私としてもデジサートや販売代理店が伝えてきた通り、DMARC 対応を先に完了してから VMC 発行に進むべきと考えており、それを破線矢印として表現しています。

                                    BIMI 対応したメール配信をやってみた

                                    ロゴの商標登録

                                    autobahn.email はトライコーンの メール配信API 国内キャリアメール対応MTA「autobahn」 サービス向けのドメインで、サービスローンチの際に以下のロゴを作成していました。

                                    BIMI に必要な VMC を発行するためには、ブランドロゴとして使用するロゴが商標登録されている必要があります。商標登録については下記の段取りで進めました。

                                    • 特許事務所の選定
                                      • 実際には以前からお付き合いのある特許事務所のお世話になりました。
                                    • 特許事務所への商標出願依頼
                                      • 商標出願の際、通常の手続きだと審査完了まで半年～一年かかるところ、通常より短く審査を完了する早期審査等の仕組みが存在します。今回の出願ではスピーディに審査を完了させたかったため、早期審査で出願を行うよう依頼しました。
                                    • 必要な書類やデータの提出
                                      • 商標出願にあたって必要なものについては特許事務所が具体的にサポートしてくれるため、そのフォローを受けつつ進めました。

                                    特許事務所への商標登録に関する依頼から商標登録の完了までは、トラブルもなくスムーズに進みましたがそれでもおおよそ 3~4 ヶ月ほどかかりました。早期審査の仕組みを利用しなければさらに半年以上はかかったのではないかと思います。

                                    ただし、かかった時間の大半は特許庁による審査の時間であり、特許事務所にお願いする形で行った今回の手続きでトライコーンのスタッフが実際に費やした時間は正味で数時間から半日程度でした。

                                    これらの手続きの結果、ロゴは無事 登録6486810 として商標登録されました。

                                    ちなみに、なぜ商標登録が必要なのか、疑問に思われた方はデジサート社の VMCの資格–ロゴを商標登録する方法 | DigiCert.com に解説がありますのでご確認ください。

                                    今回たまたま商標出願から行う流れだったので BIMI に関する記事に併せて載せることとしましたが、商標は先願主義の考え方が採用されていますので、本来はサービスのローンチと併せて出願、登録しておくのが望ましいですね。

                                    BIMI用SVG形式ロゴ画像データ作成

                                    VMC 発行申請にあたり、ロゴを適切なフォーマットの画像ファイルとして用意する必要があります。
                                    デジサート社が提供している BIMIの準備：ロゴの準備 | DigiCert.com を参考に SVG 形式の画像を作成しました。

                                    DKIM 対応

                                    クライゼルで DKIM 鍵発行を行い、セレクタと公開鍵情報を入手します。

                                    • セレクタ
                                      • trc_kreisel_dkim1548190403
                                    • 公開鍵 (読みやすさのため改行しています)
                                      • MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4e3Gu49oKR34QBbYsUC4R3o1zkWLA6DqNFvO
                                        ooRv+h5M3+9yxyABDBKRTtr2h1ozcI9R93YU/Kr6AmyID81FF1NA2itoJgnrPh4QaCMtMQ6st8k0z3MP
                                        WtdDCLMIiroUjrXZaexejqGUJGSLJF8MTQKymbExjU/t/oQDvwNuGALtKh22EaY7pOamrqk4GaJaGypR
                                        U0Wk23Xhztp2VCSaex1h8NR7tsWyFmKQpfkFigoFHiMHrWuKPwTucFlXspU8RDHoNydR6ACPZrw8hMLa
                                        J7D07+xvQnB1UcOL/z5eRv6qtF3lXlNkTYx5IkOZeWZXXzxPnNQa9wNtpuuEFAHI9QIDAQAB

                                    DKIM 向けの DNS レコードの設定を行います。AWS Route53 上で下記のように設定を行います。

                                    • AWS Route53 ダッシュボード画面から「ホストゾーン」→「autobahn.email」を選択
                                    • 「レコードを作成」をクリック
                                    • レコード作成方法としてクイック作成 (ウィザードではない方) を選択
                                      • レコードタイプを TXT に変更
                                      • レコード名の入力窓に <セレクタ>.__domainkey を入力
                                      • 値に “v=DKIM1;k=rsa;p=<公開鍵>" を入力
                                      • TTL (秒) は「1分」をクリックして 60 に設定
                                        • 設定に誤りがあって修正する場合の事を考え、反映時間の短縮のため短めにしていますが、その分 Route53 へのリクエスト回数が増えやすく(= 料金が増えやすく) なりますので、VMC 受領後にある程度長い時間にしておくと良いでしょう。以降の DMARC, BIMI 対応のためのレコードの設定も同じ理由で 60 にしています。
                                      • 必要な値の入力が終わったら、「レコードを作成」をクリック

                                    設定が終わると、下記のように問い合わせの結果が得られるようになります。

                                    Plain Text

                                    DMARC 対応

                                    DMARC 向けの DNS レコードの設定を行います。AWS Route53 上で下記のように設定を行います。

                                    • AWS Route53 ダッシュボード画面から「ホストゾーン」→「autobahn.email」を選択
                                    • 「レコードを作成」をクリック
                                    • レコード作成方法としてクイック作成 (ウィザードではない方) を選択
                                      • レコードタイプを TXT に変更
                                      • レコード名の入力窓に _dmarc を入力
                                      • 値に “v=DMARC1; p=reject;" を入力
                                      • TTL (秒) は「1分」をクリックして 60 に設定
                                      • 必要な値の入力が終わったら、「レコードを作成」をクリック

                                    設定が終わると、下記のように問い合わせの結果が得られるようになります。

                                    Plain Text

                                    DMARC について、以下のような無料で利用可能なチェックツール (利用は自己責任) もありますので、書式のチェックなどはそのようなツールを活用するなどしておくと、その後の VMC 発行を進める上で安心でしょう。

                                    VMC 購入手続き

                                    購入に関しては、デジサートの VMC を扱う販売代理店として アイビーシー株式会社 様に手配を進めて頂きました。

                                    デジサートは DigiCert 認証マーク 証明書 (VMC) にて購入の前段として以下の準備を進めるよう案内しています (以下の 1~3 は 2022年9月時点のウェブサイト上の表現を引用しています)。上記の準備でこれらがクリアされているため、購入のフェーズに進めることになります。

                                    1. DMARCに準拠する。
                                      • 現在のドメインの状態を確認します。VMCを利用するには、DMARCレコードに「p=quarantine」または「p=reject」が設定されている必要があります。
                                    2. ロゴが商標登録されているかどうか確認してください。
                                      • VMCを発行する前に、組織のロゴが適切な商標機関に登録されている必要があります。
                                    3. ロゴが適切にフォーマットされているか確認してください。
                                      • VMCのロゴは、お客様の受信箱に表示するために適切な svg 形式でなければなりません。

                                    VMC 発行手続き

                                    VMC の発行手続きについてはガイド文書としての ユーザ向け CertCentral 簡易ガイド -認証マーク証明書(VMC)- といったものが提供されており基本的にはこちらに沿って進めました。具体的には以下のような手続きを行いました。

                                    • 発注
                                    • 販売代理店からのバウチャーコードの受領と、デジサートによる証明書発行ポータルサイト CertCentral アカウント発行連絡受け取り
                                    • CertCentral から VMC 発行申請
                                      • バウチャーコードに添付されるリンクから CertCentral へアクセスし、SVG 形式のロゴ画像ファイルのアップロードや組織や担当者の情報を入力の上で申請
                                    • デジサートによる認証手続き (同時並行ではなく、上から順次実施しました)
                                      • ドメイン認証
                                        • 申請したドメインの所有者であることを確認する手続きになります。
                                        • 確認手続きは以下のようなものが用意されていました。
                                          • 該当ドメインのメールアドレスに対してメールを送ってもらい、メールに記載された URL にアクセスする形式での認証
                                          • 該当ドメインを用いているサイトにファイルを設置する形式での認証
                                          • 該当ドメインの DNS レコードに指示された値を設定する形式
                                        • 今回はメールによる認証を選びました。 admin@autobahn.email に対してデジサートからメールを送ってもらい、メール内の認証用 URL へアクセスすることでドメインの認証が完了しました。
                                      • 組織認証
                                        • 組織の実在性を確認する手続きになります。
                                        • デフォルトは電話による認証になりますが、代表電話が開いていないといった場合にはセキュリティコード郵送による認証といったオプションもあり、今回はそちらを利用しました。
                                        • このセキュリティコード郵送方式では、まず申請組織の人事担当者宛にセキュリティコードと連絡先電話番号を記載した認証書類が郵送されます。認証書類を受け取った担当者は記載された電話番号宛に連絡を行い、デジサート担当者にセキュリティコードを伝えます。これによって組織認証が完了します。
                                      • 申請者についての個人認証
                                        • 申請者自身の認証手続きになります。
                                        • こちらでは、まず申請者が自身の写真付き身分証明書（例えば運転免許証）のデータ (スマホで撮ったものなど) をデジサート指定のサイトにアップロードします。
                                        • その後、デジサートの担当者とのWebミーティング（Zoom）の日程調整を行います。時間は15分～30分程度です。
                                        • Webミーティングでは、アップロードした身分証明書について申請者自身が実際に所持していることの確認が行われました。これにて申請者個人の認証が完了します。
                                      • 公証人による承認手続き
                                        • 最後に公証人による承認手続きを行いました。
                                        • 具体的にやったことは行政書士との面談になります。こちらもWebミーティング（Zoom）となり、まずは15分～30分程度の時間を確保できるよう申請者と行政書士との間での日程調整を行いました。
                                        • この面談中に行政書士の案内に従って所定の書面に氏名や連絡先、所属組織や身分証明書情報を手書きで記入し、それをスキャン (今回はスキャナが利用できなかったのでスマホで撮影) したデータを所定のサイトにアップロードしました。
                                        • これによって公証人による承認の手続きが完了します。
                                      • 申請者による発行の承認
                                        • 上記手続きが全て完了すると、申請者に対して発行承認メールが送られてきます。こちらについて承認することで証明書が発行されます
                                        • 発行された証明書は CertCentral からダウンロードできる状態になります。

                                    発注から VMC の発行まで、今回は 4 週間弱かかりました。手順が並列ではなく逐次であるところと、Webミーティング 2 回と組織認証 (セキュリティコード郵送方式) のために、3 回分社内外の人間の日程調整が入ったところが一番大きかったかなと思います。日程調整がどの程度スムーズに進むか次第で大きく変わりそうですが、週一ペースで面談が進むといった状況であればおおよそ1ヶ月ぐらいはかかるイメージを持っておくのが安全そうです。なお、デジサートが丁寧にフォローしてくれることもあり、各手続きについて手間ではあるものの、専門的な知識や技術が必要な難しいものは特にありませんでした。やろうと思えばどなたでもできる手続きになっているなと感じました。

                                    申請者として費やした時間は、今回はおおよそ 10 時間程度はかかったかと思います。ただ不慣れな部分が大きかったため、同じことを今後するのであれば面談や日程調整などの時間を含めても 3 時間程度で済むのではないかなと感じています。

                                    VMC の受領

                                    VMC は申請者自身で CertCentral からダウンロードして入手します。受領した証明書ファイルには以下の 3 種類の証明書データが含まれていました。なお、個人的に気になったので調べてみたものの、BIMI 対応するにあたってファイルの中身まで確認する必要はありません。

                                    (1) autobahn.email ドメイン向けの VMC 本体 (トライコーン社の情報が載っている他、対応するブランドロゴファイル (svg 形式の) との関係なども載っているようです)

                                    Plain Text

                                    (2) VMC の発行元 (Issuer) である DigiCert Verified Mark RSA4096 SHA256 2021 CA1 に関する証明書 (いわゆる中間証明書)

                                    Plain Text

                                    (3) Root CA 証明書

                                    Plain Text

                                    VMC とブランドロゴ画像データの公開

                                    アップロードすべき以下の 2 つのファイルが手元にあるとして、こちらを公開できる場所に設置します。

                                    • VMC ファイル: autobahn.email_bimi_vmc_202202-202302.pem
                                    • SVG 形式のブランドロゴ画像ファイル: autobahn.email_bimi_vmc_202202-202302.svg

                                    今回は新しいバケットを作成する前提で作業を進めます。なお、このバケット内のオブジェクトは全て公開する前提でバケットを作成しますので、このように作成したバケットに非公開のオブジェクトを設置するようなことがないようご留意ください。

                                    AWS S3 管理画面から「バケット」に移動し、「バケットを作成」としてバケット作成画面に移動し、以下のようにバケットの作成を進めます。

                                    • バケット名: bimi.autobahn.email
                                    • AWS リージョン: アジアパシフィック (東京) ap-norotheast-1
                                    • オブジェクト所有者: ACL 無効
                                    • このバケットのブロックパブリックアクセス設定: 全てのチェックを外す
                                      • 『現在の設定により、このバケットとバケット内のオブジェクトが公開される可能性があることを承認します。』にはチェックをつける
                                    • バケットのバージョニング、デフォルトの暗号化設定
                                      • BIMI 対応の観点では任意です。
                                    • 「バケットを作成」をクリックしてバケット作成を行います。

                                    作成したバケットに移動し「アップロード」から上記の 2 つのファイルをアップロードします。

                                    アップロード完了後、対象のファイル名をクリックし、「プロパティ」画面で「オブジェクト URL」を確認します。こちらがインターネットからアクセスする際の URL になり、この後の BIMI レコードの設定で必要になります。今回は以下になりました。

                                    また、それぞれの URL にブラウザでアクセスすることで実際にファイルを参照することもできるはずであるため、確認しておきます。

                                    BIMI レコード設定

                                    BIMI 向けの DNS レコードの設定を行います。AWS Route53 上で下記のように設定を行います。

                                    • AWS Route53 ダッシュボード画面から「ホストゾーン」→「autobahn.email」を選択
                                    • 「レコードを作成」をクリック
                                    • レコード作成方法としてクイック作成 (ウィザードではない方) を選択
                                      • レコードタイプを TXT に変更
                                      • レコード名の入力窓に default._bimi を入力
                                      • 値に “v=BIMI1; l=<ブランドロゴ画像のURL>; a=<VMCのURL>" を入力
                                      • TTL (秒) は「1分」をクリックして 60 に設定
                                      • 必要な値の入力が終わったら、「レコードを作成」をクリック

                                    設定が終わると、下記のように問い合わせの結果が得られるようになります。

                                    Plain Text

                                    BIMI の検証

                                    BIMI の設定状態については BIMI Group という BIMI 推進団体が下記のようなチェックツールを提供しています。

                                    こちらのツールで実際に設定したドメインについて検査を行うと、下記のように DMARC レコード、BIMI レコード、公開されている SVG ロゴ画像と VMC が参照できるかなど、BIMI が適切に動作する状態かどうかをチェックしてくれます。メール配信の前にこれで一度確認を行っておき、設定漏れがないかを確認しておくと良いでしょう。(なお、DKIM についてはセレクタに関する情報が無いとレコードの確認ができないため、このチェッカでは確認されないようです)

                                    BIMI 対応メール配信

                                    クライゼルから差出人として support@autobahn.email を設定したメールを Gmail 宛に配信します。

                                    受信したメールについて Gmail 上で確認すると、以下のようにブランドロゴ画像ファイルが表示されていることが確認できました。

                                    念のため、「メッセージのソースを表示」から DKIM、DMARC が PASS していることも確認しました。

                                    この他に BIMI 導入に必要なこと

                                    BIMI 対応に必要な手続きについてある程度具体的にまとめてみましたが参考になりましたでしょうか。

                                    ただし、ここには既に多地点から数多く送られているメールの差出人アドレスのドメインに対して、後から DMARC, BIMI を適用する現実的な道筋については言及していません。多地点 (複数の部署であったり別組織であったり) から数多くメールが送られている場合、DKIM または SPF の設定が適切に実施されていない状態で DMARC の p=reject (または p=quarantine) だけを先行的に設定すると、本来届けるべきメールがなりすましメールと誤判定されて拒否 (または隔離) されてしまうため、そのような事故を避ける必要があります (補足: BIMI はなりすましされてないことを示す仕組みなので、DMARC のポリシーに p=none を設定している場合有効になりません)。この道筋は、概念的には以下のような流れになります。

                                    1. DMARC レコードに p=none (メールの拒否や隔離をしない) と rua, ruf (統計情報やエラー情報のレポートを受信するメールアドレスを指定する設定) を設定し、DMARC 認証 NG になっているメールについて情報収集できるようにする
                                    2. DMARC 認証 NG になっているメールのうち、本来届けるべきメールが無いかをレポートメールから分析し、そのようなメールが確認されたら、メール送信元に対して SPF or DKIM 認証にパスするよう設定を実施
                                    3. 本来届けるべきメールが DMARC の p=reject (または p=quarantine) で拒否 (または隔離) されない状態を確認後、DMARC レコードの p を none → reject または quarantine に変更
                                    4. BIMI の導入を実施

                                    このような対応を実際にはこんな風に進めた、であったり、こんな苦労があった、こんな工夫が必要だった、といった情報はまだあまり目にしていません (特に DMARC の XML 形式のレポートメールはそのままでは読みにくく、実際には何かしらの分析ツールが必要ではないかと考えられます)。トライコーンでもこのような経験を積み、その際の経験を記事などにして共有できればと思っています。

                                    まとめ

                                    そこそこ長い記事になってしまいましたが、ここまで読んで頂きありがとうございます。

                                    DMARC (p=reject適用) によってなりすましメール拒否が標準的になり、さらに BIMI の導入が進むと、届いたメールがなりすましかそうではないかすぐに見分けられるようになるので、メールを受け取る側もかなり安心できるようになりますね。

                                    メールという仕組みからなりすましが無くなり、本来のドメインの所有者や所有組織のメンバーだけが使えるようになると、その後はドメインレピュテーション (メール送信者アドレスのドメインに対してのユーザの評価) がメールの受信や拒否に対して大きな影響を及ぼすようになるのではないかと考えられます。このドメインレピュテーションをメールの良し悪しの判定に用いる手法は迷惑メールへの対策として既に存在していますが、現状はドメインのなりすましが容易なためまだ支配的な影響までは及ぼしていないように感じています。今後なりすましが無くなると第三者は自身が所有しないドメインをメール送信者のメールアドレスとして使えないため、ユーザの評価は本来の送信者に対しての正当なものとなります。ユーザにとって望むメールを送る送信者の評価は上がり、望まないメールを送る送信者の評価は下がってメールが受け付けられにくくなる未来が来るのかもしれません。

                                    このような未来はメールを受け取る側としてはステキなことですが、メールを送る側にとってはある意味でシビアな状況と言えるかもしれません。より一層メールを受け取るユーザの目線に立って、望む情報を提供しようとするスタンスが必要になりそうです。

                                    今回の記事ではトライコーンが提供するサービスの一つであるクライゼルでメール配信を行いましたが、その他に提供するサービスでも同様に DKIM 対応のメール配信が行なえます。ご興味を持たれた方はお問い合わせ頂ければ幸いです。

                                    morikawa

                                    Posted by morikawa