アカウント名:
パスワード:
ストーリーだと送信側の問題のようにも読み取れるけど、実際には受信側の問題だよね。迷惑メール防止機能の解除を行ったのにもかかわらずこの状態なのかも知りたい。
微妙な問題だけどメールの大量配信をするにはそれなりのお作法が必要なんです。ASPやSaaSで提供されているメール大量配信サービスとかはそのお作法に則ったシステムで、則っていないとアカウント乗っ取りや踏み台等とみなされSPAMの配信元判定をもらってしまう事があるんです。岡山の防災サイトを見ると>現在、Apple社製のスマートフォン等で使用されているメールアドレスの末尾が「@icloud.com」、「@me.com」、「@mac.com」のメールアドレスへの防災情報メールの配信ができない状況となっております。とあるので、Appleのメールサーバーに対して大量にお作法にのっとっていないメールを投げつけたんだろうなーって。
docomo宛だとhttps://www.nttdocomo.co.jp/service/imode_mail/notice/mass_send/ [nttdocomo.co.jp]この辺ですかね。
ただ、コトがコトだけに悠長に送ってるヒマは無いわけで・・・緊急の場合はエリアメールを使う、そうでない場合は作法にのっとって防災情報メールで流す、というような使い分けになるでしょうか。
それが一番かと思いますねえ。
スパム判定の大きな要因として、記載いただいたdocomoのリンクにもありますが宛先の無いメールアドレス宛に大量メール送信というのがあります。
何かに登録するときの空メール受信や、メールマガジンを作った後、定期的に送信しないとメールマガジン自体が停止される、というのは手入力で存在しないメールアドレスを登録させない、定期的にメールを送信してもういなくなったメールアドレスを除外していく、という上記の対応でもあるんです。
これを許可すると、メールアドレスが存在するかどうかを確認するようなランダムなメール送信まで許可されてしまい、SPAM送信先リストが完成されてしますというわけです。
特にEメールで運用する場合、ここがデリケートな部分なのでこのメンテナンスを常時行えるような運用が求められるんですが、緊急時のみ運用したいという目的と相反するので手段を目的別に分けるか、運用方法を変えるかしないと根本的な解決はしないんじゃないかな、と思います。
3000のアドレス以外にも遅延したのは送信側の問題じゃないですかね再送は通常送信とは違うキューで管理とかしてなかったのかしら
エラーとした受け取り側も単に切断とかエラーにするんじゃなくてSPAM対策で応答返すのを遅くしてる、とかになってたのならまだ多少同情できる…かな
いや、メールの大量送信システムでエラー応答待ちで後続が詰まるようなのは初歩的な設計ミスでしょ。SPMA扱いされて届かない3,000通についてはともかく、全体の送信が遅延したのは完全に送信側の問題だし、いくらなんでもこれはない。
送信側のメールのドメインにもよるけど、ちゃんとした自治体からのメールは迷惑メール対象外にすればいいのに。と思ったけど、ウェブ見ると xxx.okayama.jp からのメールになるのね。この汎用ドメイン、誰でも取れるから信頼性にはならんか。と思ったけど、もうドメイン取れなくなってるのね。まぁクソドメインだからしょうがないけど。
なんで地方自治体に go.jp 使わせてあげないんだろう。アメリカだと、州の公式サイトも .gov 使ってる。合衆国で州政府という認識だからわかるけど、都市単位でも .gov 使ってるところが多い。
中央政府にまともに情報やIT扱える部署なんかがあるかないかの違いなのかな・・・
lg.jpというドメインがあってですね・・・
そんな韓国企業の日本法人みたいなアドレスから送られてきても読まないだろうなぁ。
可哀想な ad.jp ...広告用じゃないんです
まえに自治体関係の仕事したとき，内部や県とのやり取りではlg.jpドメイン（非公開），市民や外部向けには.jp汎用ドメインとメールやサイトのドメイン使い分けている自治体がいくつもあったな．
そういうシステム屋さんがいるのかな．
つ https://www.j-lis.go.jp/lgwan/about/cms_15039.html [j-lis.go.jp]
.govとかgo.jpがアドレスバーに表示されたら、個人情報収集目的のドメイン詐称か偽サイト誘導を疑われるかな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
身近な人の偉大さは半減する -- あるアレゲ人
送受信 (スコア:1)
ストーリーだと送信側の問題のようにも読み取れるけど、実際には受信側の問題だよね。
迷惑メール防止機能の解除を行ったのにもかかわらずこの状態なのかも知りたい。
Re:送受信 (スコア:2, 参考になる)
微妙な問題だけどメールの大量配信をするにはそれなりのお作法が必要なんです。
ASPやSaaSで提供されているメール大量配信サービスとかはそのお作法に則ったシステムで、則っていないとアカウント乗っ取りや踏み台等とみなされSPAMの配信元判定をもらってしまう事があるんです。
岡山の防災サイトを見ると
>現在、Apple社製のスマートフォン等で使用されているメールアドレスの末尾が「@icloud.com」、「@me.com」、「@mac.com」のメールアドレスへの防災情報メールの配信ができない状況となっております。
とあるので、Appleのメールサーバーに対して大量にお作法にのっとっていないメールを投げつけたんだろうなーって。
Re: (スコア:0)
docomo宛だと
https://www.nttdocomo.co.jp/service/imode_mail/notice/mass_send/ [nttdocomo.co.jp]
この辺ですかね。
ただ、コトがコトだけに悠長に送ってるヒマは無いわけで・・・
緊急の場合はエリアメールを使う、そうでない場合は作法にのっとって防災情報メールで流す、
というような使い分けになるでしょうか。
Re:送受信 (スコア:1)
それが一番かと思いますねえ。
スパム判定の大きな要因として、記載いただいたdocomoのリンクにもありますが宛先の無いメールアドレス宛に大量メール送信というのがあります。
何かに登録するときの空メール受信や、メールマガジンを作った後、定期的に送信しないとメールマガジン自体が停止される、というのは手入力で存在しないメールアドレスを登録させない、定期的にメールを送信してもういなくなったメールアドレスを除外していく、という上記の対応でもあるんです。
これを許可すると、メールアドレスが存在するかどうかを確認するようなランダムなメール送信まで許可されてしまい、SPAM送信先リストが完成されてしますというわけです。
特にEメールで運用する場合、ここがデリケートな部分なのでこのメンテナンスを常時行えるような運用が求められるんですが、緊急時のみ運用したいという目的と相反するので手段を目的別に分けるか、運用方法を変えるかしないと根本的な解決はしないんじゃないかな、と思います。
Re:送受信 (スコア:2)
3000のアドレス以外にも遅延したのは送信側の問題じゃないですかね
再送は通常送信とは違うキューで管理とかしてなかったのかしら
エラーとした受け取り側も単に切断とかエラーにするんじゃなくてSPAM対策で
応答返すのを遅くしてる、とかになってたのならまだ多少同情できる…かな
Re:送受信 (スコア:1)
いや、メールの大量送信システムでエラー応答待ちで後続が詰まるようなのは
初歩的な設計ミスでしょ。
SPMA扱いされて届かない3,000通についてはともかく、全体の送信が遅延したのは
完全に送信側の問題だし、いくらなんでもこれはない。
Re: (スコア:0)
送信側のメールのドメインにもよるけど、ちゃんとした自治体からのメールは迷惑メール対象外にすればいいのに。
と思ったけど、ウェブ見ると xxx.okayama.jp からのメールになるのね。
この汎用ドメイン、誰でも取れるから信頼性にはならんか。
と思ったけど、もうドメイン取れなくなってるのね。まぁクソドメインだからしょうがないけど。
なんで地方自治体に go.jp 使わせてあげないんだろう。
アメリカだと、州の公式サイトも .gov 使ってる。合衆国で州政府という認識だからわかるけど、都市単位でも .gov 使ってるところが多い。
中央政府にまともに情報やIT扱える部署なんかがあるかないかの違いなのかな・・・
Re: (スコア:0)
lg.jpというドメインがあってですね・・・
Re:送受信 (スコア:1)
そんな韓国企業の日本法人みたいなアドレスから送られてきても読まないだろうなぁ。
Re: (スコア:0)
可哀想な ad.jp ...
広告用じゃないんです
Re: (スコア:0)
まえに自治体関係の仕事したとき，内部や県とのやり取りではlg.jpドメイン（非公開），市民や外部向けには.jp汎用ドメインとメールやサイトのドメイン使い分けている自治体がいくつもあったな．
そういうシステム屋さんがいるのかな．
Re: (スコア:0)
つ https://www.j-lis.go.jp/lgwan/about/cms_15039.html [j-lis.go.jp]
Re: (スコア:0)
.govとかgo.jpがアドレスバーに表示されたら、
個人情報収集目的のドメイン詐称か偽サイト誘導を疑われるかな。