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
なんで「pref.kanagawa.lg.jp」を使わないの？ (スコア:3)
「shutsugankanagawa.jp」なんてドメイン、スパム扱いされて当然じゃん
地方自治体なんだからlg.jp使いなよ
っていうか国は政令とか法律で「地方自治体が適当に*.jpドメインを取得することを禁止する。どうしても必要な場合は20年以上継続させる義務を負う」みたいなルール作ろうぜ
https://twitter.com/wakwak_koba/status/1747183872969003179 [twitter.com]
whoisでも神奈川のかの字もないそうで…
なんでこんなドメインが信用されると思ったのか
Re:なんで「pref.kanagawa.lg.jp」を使わないの？ (スコア:1)
部署が違うからでしょ
政府のデジタル省みたいな感じで横断的にやらせないと役所の縦割り構造は崩せないと思う。
Re:なんで「pref.kanagawa.lg.jp」を使わないの？ (スコア:1)
縦割りとかじゃなくて、担当者ごとに適当に決めてんじゃないの
リンク先の令和6年1月17日13時掲載（第9報）によると、ドメイン名が三つもある
> また、出願システムの利用者におかれましては、以下のメールアドレスを受信できるよう、設定をお願いします。
> shutsugan[アットマーク]mail.shutsugankanagawa.jp
> shutsugan[アットマーク]mail.shutsugan-kanagawa.jp
> shutsugan[アットマーク]mail.nyuushi-kanagawa.jp
Re:なんで「pref.kanagawa.lg.jp」を使わないの？ (スコア:2)
建前論をぶつなら、.lg.jp以外から公的なメールが出ちゃダメなんじゃないかと。shutsugankanagawa.jpとかnyuushi-kanagawa.jpは公的なドメインではないので、公的機関を騙ったにせメールである、と言い切っても形式的には言い過ぎではないはず。
これ、縦割りとかではなく、外部の業者が.lg.jpを触れない、触る技術や業務の枠組みがない問題じゃないかと思うんですけどね。専門家に権限がなく権限者に能力がなければこうなるでしょう。
Re: (スコア:0)
「@gmail.com宛が24時間に5,000通」に引っかからないようドメインを分けたという説をXで見かけた。
https://twitter.com/esumii/status/1747548497073844483 [twitter.com]
Re: (スコア:0)
本件やらかしたクソ田舎のクソSIerにそんなこと考える知能があると思うか?
Re: (スコア:0)
デジタル庁「TXTレコードにマイナンバーカードの証明書を入れて本人確認できるようにしよう」
Re: (スコア:0)
ドメイン名でスパム判定するような運用の方がどうかと思うが。
その逆でルール違反しててもlg.jpなら大目にみるなんてのも論外。
もうちょっと考えてものを言いなよ。
Re:なんで「pref.kanagawa.lg.jp」を使わないの？ (スコア:1)
担当者の怠慢や責任者の無理解で、将来、失効して、
悪意のある第三者に「正規に」取得される可能性のある汎用JPドメインと、
レジストラがミスしない限り、
そこまで酷いことにはならないことが期待出来るlg.jpドメインとでは
大きく違うと思う。
プレミアムフライデーやGo To Eatキャンペーンでも同様の指摘はあったし
https://it.srad.jp/story/23/08/01/1228225/
https://it.srad.jp/story/23/10/22/149248/
Re: (スコア:0)
lg.jpのメアドなら必ずスパム扱いにされないわけじゃないので、ホスト名変えるのはスパムの解決にならないよ。
Re: (スコア:0)
国はそういうことを地方自治体に強制できないのです(「自治」って言葉の意味はお分かり?)
Re: (スコア:0)
強制しなくとも、共通サービス基盤とガイドラインを提供すればアホ以外は使うだろ。
違うよ、全然違うよ (スコア:2)
Gmailで送信されたメールが受信できない不具合
出願システムから出願者宛に送るメールが、出願者側のメールアカウントがGmailだと正常に受信されない不具合
だよ。
あと確かに解消はされていないようだけどストーリー投稿時点では一応の対応策が県から提示されている。
スラド民的には原因が何なのか [togetter.com]のほうが興味あるでしょ。
Re: (スコア:0)
これは送信元の出願システムのメール送信まわりが終わってて、Gmail側はむしろ適切に処理してるという話なのかな
Re: (スコア:3)
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箱をネットに繋いで送るのだと思ってると弾かれます。そんな感じでメールを大量送信しようとして順当に弾かれたんでしょう。
Re: (スコア:1)
今時SPF、DKIM、DMARC全滅のヘッダは珍しいですね久々に見ましたよ
# 全滅で許されるのは触りたての学生までだよねぇみたいな（受信してもらえるとは言っていない
Re: (スコア:1)
> 一定期間を置かないと(DNS浸透ではない)
これはGoogleが独自にキャッシュしているってこと? そうでないなら「一定期間を置かないと」と言っている時点でDNS浸透という言葉を避ける意味が理解できていないことになるが
Re: (スコア:0)
今回の件がそれだって言いたいわけじゃないんだけど、
複数台のサーバー・ワーカーへのポリシー配布とかは一定期間待たないと反映されなかったりするね。
独自にキャッシュという言い方なら、ワーカーのキャッシュということで合っていると思う
Re: (スコア:0)
DNS プロトコル外でキャッシュしているので TTL の指定を守っていないわけではなさそうだが、
SPF/DMARC では DNS プロトコル外でキャッシュすることを許しているのか？
TTL を超えてキャッシュすることについて禁ずる規定があっても良さそうに思う。
Re: (スコア:0)
gmailは最近DMARC周りの拒否が厳しいからでしょ。
Re: (スコア:0)
一昨年あたりから、SPFレコード無いドメインのメールがGmailで突然受信できなくなる例をちらほら見ている。
今回の送信側が終わってるのは間違いなくそうだけど、なりすまし対策未対応メール全捨てポリシーもそれはそれで。
Re: (スコア:0)
この検証記事によればSPFもDMARCも問題はないとのことだけどね
https://dev.classmethod.jp/articles/shutsugankanagawa-email/ [classmethod.jp]
Re: (スコア:0)
問題が有ったのはMXレコードで、MXレコードが直った後の記事だから問題がなくて当然。
＞「dig」コマンドを利用して、SPF、DKIM、DMARCで利用するDNSレコードの確認を試みました。(確認時刻:1月16日22時台)
Re: (スコア:0)
MXレコードはメール受信の設定ですが、送信にも影響があった証拠はあるのでしょうか？
Re: (スコア:0)
Googleの中の人ではないから明確な原因解明は無理ですが、
エラーメールを送り返す先のメールサーバーに繋がらないのは、ブロックされる理由として十分ですよ。
Re: (スコア:0)
西風が吹けば…くらいの影響のような。
（昔からIPアドレス直書きするミスは良くあったし、MX自体がなくて仕方なくAを直接引いて送るのもよくあった。また今回は優先度20は正しい記述で繋がらないわけじゃない）
もし 彼らがそれを十分な理由にするなら、今回からDMARC/SPF/DKIM/TLSに加えて受信側設定も厳格に見るように変える、と明示するのではと。
キャリアメールへの送信すらできない (スコア:0)
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レコードの
Re: (スコア:0)
キャリアメールすらって、彼らは昔から特殊な部類(*)だから、リファレンスにならないのでは。
RFC違反メールアドレス利用を今も許してたり。
https://service.smt.docomo.ne.jp/site/mail/src/rfcaddress_info_for_ios.html [docomo.ne.jp]
(*)キャリア内の独自プロトコルのメッセージ交換網が基本で、後付けでゲートウェイでemail交換もできるよう拡張
Re: (スコア:0)
>Gmailで、送信されたメールが受信できない不具合
と読点を入れると下手だけどぎりぎり伝わる日本語になるので、正しく読み取れなくもないけど普通は読み取れない下手すぎる日本語、というレベルであって、2回繰り返して違うと断言する程には違わない。
Re: (スコア:1)
そこだけを切り取ればそうかもしれないけど、全文読むと駄目だと思う。
この文章で「インターネット出願システムが送信したメールをGmailで受信できない」という風に読めるのはエスパー。
Re: (スコア:1)
日本語って文法バグ仕込みやすいよね…。
でも、ここから真意を読み取るのが俺らSE/プログラマーの仕事。文中から矛盾見つけたり他の資料との相違を見つけてツッコミ入れるのが仕事。国語か。
実際今回の悪文というかバグ文レベルの文章力の要件定義はしょっちゅうだからねぇ。
読解力ない人が多くてクラクラするけど、作文能力ない人も相応に多いね。
とはいえ、本件についてはGmail使うな、ってことだけユーザー(受験生)に伝われば良いので、こんな文でも役に立つんだよな…。
Re: (スコア:1)
論理的な文章が書けない理由を言語に求めるのは非論理的
Re: (スコア:0)
＞日本語って文法バグ仕込みやすいよね…。
日本語以外の言語は違うの？
Re: (スコア:1)
神奈川県側からの公式回答は、
となってます。
この文もなんか紛らわしい表現ですが、Q&Aに
というのもあるので、
出願システム→gmailの方向なのは確かでしょう。
MX(出願システムが受け取る側のDNS設定)がおかしい、という分析はされてますが、
preference=20で正しい記述も一行あるので、
普通のMTAならそこに送るので一応大丈夫なはず。
出願システム→gmailの方向では、出願システムのMX設定は直接は関係ないんだけど、
gmailはそういいとこもチェックしてスパム扱いしててもおかしくないと思います。
Re: (スコア:0)
IPの末尾にドット付けて無理くりFQDNにしてあったな。
送信側はhostsかなんかでIPが引ければ送れはするが、受信側はなんだかよくわからないドメインから届くことになるから、
SPAM判定されていたとかか？
しかしこれ2月からのSPAMフィルター強化でえらいことになるのでは。
ホスティングしてるBizメール＆ウェブはDMARC Record Checkerで確認したらアウトだったｗ
2月までにはなんとか！ってアナウンス出てたけど、もう1/17だが大丈夫なんかい。
Re: (スコア:0)
この文章で「インターネット出願システムが送信したメールをGmailで受信できない」という風に読めるのはエスパー。
さすがにエスパー盛りすぎかなぁ
Gmail絡みの受送信問題なら迷惑メール対策でDNSのTXTレコード不備くらい思い至るのがスラド民的アレゲの標準かと
# さすがにGmail絡みの受送信問題今知ったとかならスラド見に来ている場合じゃなかろうみたいな
そーゆーことか (スコア:1)
受信条件が厳しいGmail に対するスキルの低いエンジニアの意趣返しかとおもった
Re: (スコア:0)
gmailだと受信できませんみたいな話はちょくちょく聞くからね
受験のような大事な場面でgmailを使った受験者の落ち度でもあると思う
Re: (スコア:0)
最近↓のような記事を読んだので、先行適用が始まったか？ とか思ったが貼ってもらったリンク先を読んだらそんなんじゃなかった。
これ、Gmail以外でも受信不可がありそうな…
「Gmail」、迷惑メールを抑止するための新しいポリシーを2024年2月までに適用開始
https://forest.watch.impress.co.jp/docs/news/1561070.html [impress.co.jp]
Re: (スコア:0)
どうせ spf レコード誤設定とかだろ、と思ったらそれ以上の何かだった…。
MXレコードの書き方とかあんま詳しくはないのだけど、IPじゃ駄目なんだね。Aかcnameでつけた名前を書くのか。
慌てて直してるって話があるが、結果どうなったんだろうな。
ちゃんと開通してるのかなー。
Re: (スコア:0)
MXやNSはcnameで付けたホスト名も駄目だよ。
AやAAAAレコード限定。
Re: (スコア:0)
以前ユニクロとGUのアプリにGmailで登録したら、確認のメールが飛んでこなくて使うのやめたけど、この関係なのかな
次の問題予想 (スコア:1)
次はキャリアメールのRFC違反アドレスでエラーが出るだろうと思ったけど
中学生なら最初からRFC準拠のメールアドレスしか取れないか
Re: (スコア:0)
quoteすればRFC違反じゃない定期
適当なドメインでメールサーバーを建てるから (スコア:0)
神奈川県のメールサーバー上で、公立高等学校入学者選抜インターネット出願システムのアカウントを作ればよいのに
Re:適当なドメインでメールサーバーを建てるから (スコア:1)
神奈川県のメールサーバー上で、公立高等学校入学者選抜インターネット出願システムのアカウントを作ればよいのに
神奈川県のメールサーバーがSPF、DKIM、DMARC、etc...しっかり設定されている保証があるのだろうか
# Gmailが迷惑メールで弾いてるってはなしかと
Re: (スコア:0)
使う側の技術力がへっぽこってのはあるが
そうはいっても規格側の高飛車度合いも相当なもんなんですよねぇ
既に実用化されて何年たったかって感じなのに未だにゴニョゴニョ個別に設定しないとメール一つ受け入れてもらえない仕組み
時代的にはメールサーバーとDNS選んでドメイン指定したらサクッと設定完了くらいには技術が進んでいるはずなんですけど
このあたりの設定に未だ20世紀の泥臭さがしぶとく残っている
普及させる側の老齢化のせいなんでしょうね
簡単にできるが迂闊にやると即ブラックリスト入りって感じのバランスになるくらいがちょうどいいんじゃないかと思うんだがなぁ
# 個人的には泥臭いのは嫌いではないが若者育てるにはダメな仕組みなんだよねぇ
SPFへの入れ忘れとか (スコア:0)
実際にメール配信を行うサーバをSPFの記述に含めてないとか、そういうよくある
パターンかも
SPFで止めたメールの発信元ドメインのTXT見ると、SPFは書いてある
なので、ｍおそらくそのメールを発信したサーバはSPFに含まれてない
ログ見てると、大企業のメセナ部門や政府機関からのメールがそれで止まることが多い印象
Re:SPFへの入れ忘れとか (スコア:1)
実際にメール配信を行うサーバをSPFの記述に含めてないとか、そういうよくある
で含めすぎてlookup 10回制限越えでアウト
lookup分解して対処したら文字数オーバーでアウト
オーバー分を2行目にしちゃってアウト
とかになるまでがテンプレ
/*
サービス側がFrom用ドメインSMTP認証に対応しているとサービス側のSPF関連気にせずに済むんだけどねぇ
え？今回はそもそも自分とこが腐ってた親方日の丸あるある？
しかたないねー
*/
Re: (スコア:0)
冗談でもそういう混ぜっ返しは止めてもらいたい