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
違うよ、全然違うよ (スコア: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)
DNSレコードはキャッシュしてなくとも、各サーバーのスパマー判定評価スコアはキャッシュするだろ。
Re: (スコア:0)
至極ごもっともだが、前回参照が失敗した場合、そのTTLすらもらえないわけでな。
Re: (スコア:0)
失敗の定義によるが、 DNS レコードが存在しない場合のネガティブキャッシュには TTL が存在するし、
存在も不在も分からない検索失敗の場合には最長 5 分では?
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交換もできるよう拡張