パスワードを忘れた? アカウント作成

神奈川県の高校入試出願システムで障害、Gmail以外を使用するよう求められる事態に」記事へのコメント

  • Gmailで送信されたメールが受信できない不具合

    出願システムから出願者宛に送るメールが、出願者側のメールアカウントがGmailだと正常に受信されない不具合
    だよ。
    あと確かに解消はされていないようだけどストーリー投稿時点では一応の対応策が県から提示されている。
    スラド民的には原因が何なのか [togetter.com]のほうが興味あるでしょ。

    ここに返信
    • by Anonymous Coward

      これは送信元の出願システムのメール送信まわりが終わってて、Gmail側はむしろ適切に処理してるという話なのかな

      • by 90 (35300) on 2024年01月17日 16時51分 (#4594941) 日記

        550-5.7.26 This mail has been blocked because the sender is unauthenticated.
        550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.
        550-5.7.26
        550-5.7.26 Authentication results:
        550-5.7.26 DKIM = did not pass
        550-5.7.26 SPF [fqdn.example.net] with ip: [0.0.0.0] = did not pass
        550-5.7.26
        550-5.7.26 To mitigate this issue, please visit Gmail's authentication guide
        550-5.7.26 for instructions on setting up authentication:
        550 5.7.26 https://support.google.com/mail/answer/81126#authentication [google.com]
        *********************** - gsmtp

        最近ちょっと興味があって触ったんですが、適切にDNSをいじくった上で一定期間を置かないと(DNS浸透ではない)、こんな感じのおしらせが返ってきます。設定には多少の専門知識とDNSサーバの設定権限が必要ですが、その通り設定すると受けてくれますし、やらんでおいてメールというのは適当なLinux箱をネットに繋いで送るのだと思ってると弾かれます。そんな感じでメールを大量送信しようとして順当に弾かれたんでしょう。

        • by Anonymous Coward on 2024年01月17日 17時53分 (#4594994)

          今時SPF、DKIM、DMARC全滅のヘッダは珍しいですね久々に見ましたよ

          # 全滅で許されるのは触りたての学生までだよねぇみたいな(受信してもらえるとは言っていない

        • by Anonymous Coward on 2024年01月17日 18時34分 (#4595033)

          > 一定期間を置かないと(DNS浸透ではない)

          これはGoogleが独自にキャッシュしているってこと? そうでないなら「一定期間を置かないと」と言っている時点でDNS浸透という言葉を避ける意味が理解できていないことになるが

          • by Anonymous Coward

            今回の件がそれだって言いたいわけじゃないんだけど、

            複数台のサーバー・ワーカーへのポリシー配布とかは一定期間待たないと反映されなかったりするね。
            独自にキャッシュという言い方なら、ワーカーのキャッシュということで合っていると思う

            • by Anonymous Coward

              DNS プロトコル外でキャッシュしているので TTL の指定を守っていないわけではなさそうだが、
              SPF/DMARC では DNS プロトコル外でキャッシュすることを許しているのか?
              TTL を超えてキャッシュすることについて禁ずる規定があっても良さそうに思う。

              • by Anonymous Coward

                DNSレコードはキャッシュしてなくとも、各サーバーのスパマー判定評価スコアはキャッシュするだろ。

              • by Anonymous Coward

                至極ごもっともだが、前回参照が失敗した場合、そのTTLすらもらえないわけでな。

              • by Anonymous Coward

                失敗の定義によるが、 DNS レコードが存在しない場合のネガティブキャッシュには TTL が存在するし、
                存在も不在も分からない検索失敗の場合には最長 5 分では?

      • by Anonymous Coward

        gmailは最近DMARC周りの拒否が厳しいからでしょ。

      • by Anonymous Coward

        一昨年あたりから、SPFレコード無いドメインのメールがGmailで突然受信できなくなる例をちらほら見ている。
        今回の送信側が終わってるのは間違いなくそうだけど、なりすまし対策未対応メール全捨てポリシーもそれはそれで。

      • by Anonymous Coward

        この検証記事によればSPFもDMARCも問題はないとのことだけどね
        https://dev.classmethod.jp/articles/shutsugankanagawa-email/ [classmethod.jp]

        • by Anonymous Coward

          問題が有ったのはMXレコードで、MXレコードが直った後の記事だから問題がなくて当然。

          >「dig」コマンドを利用して、SPF、DKIM、DMARCで利用するDNSレコードの確認を試みました。(確認時刻:1月16日22時台)

          • by Anonymous Coward

            MXレコードはメール受信の設定ですが、送信にも影響があった証拠はあるのでしょうか?

            • by Anonymous Coward

              Googleの中の人ではないから明確な原因解明は無理ですが、
              エラーメールを送り返す先のメールサーバーに繋がらないのは、ブロックされる理由として十分ですよ。

              • by Anonymous Coward

                西風が吹けば…くらいの影響のような。
                (昔からIPアドレス直書きするミスは良くあったし、MX自体がなくて仕方なくAを直接引いて送るのもよくあった。また今回は優先度20は正しい記述で繋がらないわけじゃない)
                もし 彼らがそれを十分な理由にするなら、今回からDMARC/SPF/DKIM/TLSに加えて受信側設定も厳格に見るように変える、と明示するのではと。

            • MXレコードを設定しないなんていうテストをしたことがないので証拠はありませんが、
              AレコードもMXレコードも正しく設定されていないと、キャリアメール宛てのメール送信ですら弾かれますよ

              https://www.docomo.ne.jp/info/spam_mail/domain/notice/ [docomo.ne.jp]

              「受信するメールの選択」内の「なりすましメールの拒否設定(パソコンなど)(iモードでは「他のアドレスになりすましたメール」)」の初期値は、2015年11月26日(木曜)以前にiモードをご契約された方は「拒否しない」、2015年11月27日(金曜)以降ご契約の方は、「存在しないドメインからは拒否する(iモードでは「存在するドメインのみ受信」)」が設定されています。

              MXレコードもAレコードも正しく設定されなていなかったら、存在しないドメイン扱いで拒否されます。

              ちなみに、MXレコードが無い場合にはAレコードの

              • by Anonymous Coward

                キャリアメールすらって、彼らは昔から特殊な部類(*)だから、リファレンスにならないのでは。
                RFC違反メールアドレス利用を今も許してたり。
                https://service.smt.docomo.ne.jp/site/mail/src/rfcaddress_info_for_ios.html [docomo.ne.jp]
                (*)キャリア内の独自プロトコルのメッセージ交換網が基本で、後付けでゲートウェイでemail交換もできるよう拡張

    • by Anonymous Coward

      >Gmailで、送信されたメールが受信できない不具合

      と読点を入れると下手だけどぎりぎり伝わる日本語になるので、正しく読み取れなくもないけど普通は読み取れない下手すぎる日本語、というレベルであって、2回繰り返して違うと断言する程には違わない。

      • by Anonymous Coward on 2024年01月17日 13時57分 (#4594778)

        そこだけを切り取ればそうかもしれないけど、全文読むと駄目だと思う。

        神奈川県の公立高等学校入学者選抜インターネット出願システムで、Gmailで送信されたメールが受信できない不具合が1月9日以降発生しているそうだ。

        この文章で「インターネット出願システムが送信したメールをGmailで受信できない」という風に読めるのはエスパー。

        • by Anonymous Coward on 2024年01月17日 14時39分 (#4594819)

          日本語って文法バグ仕込みやすいよね…。
          でも、ここから真意を読み取るのが俺らSE/プログラマーの仕事。文中から矛盾見つけたり他の資料との相違を見つけてツッコミ入れるのが仕事。国語か。

          実際今回の悪文というかバグ文レベルの文章力の要件定義はしょっちゅうだからねぇ。
          読解力ない人が多くてクラクラするけど、作文能力ない人も相応に多いね。

          とはいえ、本件についてはGmail使うな、ってことだけユーザー(受験生)に伝われば良いので、こんな文でも役に立つんだよな…。

          • by Anonymous Coward on 2024年01月17日 16時16分 (#4594896)

            論理的な文章が書けない理由を言語に求めるのは非論理的

          • by Anonymous Coward

            >日本語って文法バグ仕込みやすいよね…。

            日本語以外の言語は違うの?

            • by Anonymous Coward

              単なる日本下げですね。
              実際RFCなんかでも意味不明な文章だからとしばしば書き直されてるわけだし。
              仕様の解釈違いで実装が異なるなんていくらでも遭遇してるでしょ。

        • by taka2 (14791) on 2024年01月17日 15時03分 (#4594836) ホームページ 日記

          神奈川県側からの公式回答は、

          主に@gmail.comにおいて出願システムからのメールが受信できないという事象が発生しています。

          となってます。
          この文もなんか紛らわしい表現ですが、Q&Aに

          すでに志願者アカウントを登録しています。ログインしようとした際に、認証コードが送られてきません。どうしたらよいですか。

          というのもあるので、
          出願システム→gmailの方向なのは確かでしょう。

          MX(出願システムが受け取る側のDNS設定)がおかしい、という分析はされてますが、
          preference=20で正しい記述も一行あるので、
          普通のMTAならそこに送るので一応大丈夫なはず。

          出願システム→gmailの方向では、出願システムのMX設定は直接は関係ないんだけど、
          gmailはそういいとこもチェックしてスパム扱いしててもおかしくないと思います。

          • by Anonymous Coward

            IPの末尾にドット付けて無理くりFQDNにしてあったな。
            送信側はhostsかなんかでIPが引ければ送れはするが、受信側はなんだかよくわからないドメインから届くことになるから、
            SPAM判定されていたとかか?

            しかしこれ2月からのSPAMフィルター強化でえらいことになるのでは。
            ホスティングしてるBizメール&ウェブはDMARC Record Checkerで確認したらアウトだったw
            2月までにはなんとか!ってアナウンス出てたけど、もう1/17だが大丈夫なんかい。

        • by Anonymous Coward

          この文章で「インターネット出願システムが送信したメールをGmailで受信できない」という風に読めるのはエスパー。

          さすがにエスパー盛りすぎかなぁ
          Gmail絡みの受送信問題なら迷惑メール対策でDNSのTXTレコード不備くらい思い至るのがスラド民的アレゲの標準かと

          # さすがにGmail絡みの受送信問題今知ったとかならスラド見に来ている場合じゃなかろうみたいな

      • by hinatan (24342) on 2024年01月17日 14時17分 (#4594795) 日記

        受信条件が厳しいGmail に対するスキルの低いエンジニアの意趣返しかとおもった

        • by Anonymous Coward

          gmailだと受信できませんみたいな話はちょくちょく聞くからね
          受験のような大事な場面でgmailを使った受験者の落ち度でもあると思う

          • by Anonymous Coward

            gmailだと受信できませんみたいな話はちょくちょく聞くからね
            受験のような大事な場面でgmailを使った受験者の落ち度でもあると思う

            運用から何年も経ってる仕様に全く追いつけない理解度と技術力が大人の世界といういい経験になったみたいな

            # 諦めて歯車になるか自ら身を立てるか選ぶことが大人になる一段目

          • by Anonymous Coward

            中学生がgmail以外で自力で取得できる比較的安全なメールアドレスを教えてください。
            (クラスに数人はITに無知な親がいるから親が取ってあげるのは無し)

    • by Anonymous Coward

      最近↓のような記事を読んだので、先行適用が始まったか? とか思ったが貼ってもらったリンク先を読んだらそんなんじゃなかった。
      これ、Gmail以外でも受信不可がありそうな…

      「Gmail」、迷惑メールを抑止するための新しいポリシーを2024年2月までに適用開始
      https://forest.watch.impress.co.jp/docs/news/1561070.html [impress.co.jp]

    • by Anonymous Coward

      どうせ spf レコード誤設定とかだろ、と思ったらそれ以上の何かだった…。
      MXレコードの書き方とかあんま詳しくはないのだけど、IPじゃ駄目なんだね。Aかcnameでつけた名前を書くのか。

      慌てて直してるって話があるが、結果どうなったんだろうな。
      ちゃんと開通してるのかなー。

      • by Anonymous Coward

        MXやNSはcnameで付けたホスト名も駄目だよ。
        AやAAAAレコード限定。

    • by Anonymous Coward

      以前ユニクロとGUのアプリにGmailで登録したら、確認のメールが飛んでこなくて使うのやめたけど、この関係なのかな

      • by Anonymous Coward

        9割以上はアドレスが間違っているか迷惑メールに放り込まれてるかだから違うと思うよ

    • by Anonymous Coward

      わたしゃ、ISPメールをGmailに転送しているんだけど、そういうのも対象になるのかな
      #今回の対象では(当然)ないけど

      • by Anonymous Coward

        独自ドメインでメールサーバー立てて、Gmailに転送するユーザーの一部に、ここ数年届かなくなってきた。
        Googleに蹴られて、送信元にエラーメールが返る。
        その場合はエラーメールから確認したGmailのアドレスに直接送るようにしているが、こちらは拒否されたことはない。

        問題は、黙ってたらずっと気づかないこと。

開いた括弧は必ず閉じる -- あるプログラマー

処理中...