アカウント名:
パスワード:
会社の一斉メールでエラーが返ってきやすいのは、ドコモのアドレスですね。しかもタチが悪いのは、エラーが返ってくるのに相手に届いているという、今回の問題とよく似た状況。
docomoに複数宛先を指定した時に、1件でもPC受信を拒否した宛先の人がいると該当宛先に対するRCPT TOの後にエラーが返るのではなくDATAの後にエラーが返る。よって、誰に送信できて誰に送信できなかったかを判断するのは送信側では不可能。RFCに非準拠と公式に回答。
対策としては、自ネットワークのMTA側でdocomoのときのみ1通ずつ送るようにするしかない。if [ $rcptdomain -eq "docomo" ];then的な処理を・・・入れる
結構有名な話ですよね？
この件、気になって情報を集めていたんですが、公式サイトの応募要領のPDFによれば( http://www.sotetsu.co.jp/news_release/pdf/140707_01.pdf [sotetsu.co.jp] )
単に応募用紙に電子メールアドレス等を書かせて、指定された場所の応募BOXに投函し、当選メールを待つというスタイルのようです。メールで当選を知らせること自体はよくあることですが、迷惑メールフィルター等が受信エラーを起こさないように、送信元のアドレスを知らせる等の案内をしているものも多く、そのような配慮は恐らくなかったと思われるこの応募スタイルでは応募者の過失を問うのは到底難しいのではないでしょうか。
そもそも受信エラーなんてどんな条件で出るかわからないしなぁ。
エラーメッセージを読まなかったり、再送したり返信を促すメールを送らずにリストから除外って感じなんですかね…
転送設定の間違いで宛先(転送先)に届かず、エラーメールが返るというのであればまだしも、今回の場合は宛先に届いているにも関わらずエラーメールが返っている、というのが問題なのでは。
確かにドコモはCcやBccで複数のアドレスを設定すると、ランダムでエラーになることがありますね。
１つの宛先でforward複数している場合もありえるから、エラーが返ったら絶対に届いてないと思うのは解釈が間違ってる。>今回の場合は宛先に届いているにも関わらずエラーメールが返っている、というのが問題なのでは。
自業自得にせよ、エラーメールは確定情報として扱うには怪しすぎますね。
この場合なら、届いたメールに書かれたURLにアクセスしたら当選が確定とかそういう運用にしとかないと。
複数の転送先が指定してあるアカウントで、その内の1つがエラーを返したけど、他のアカウントでは無事に届いて居るので内容は伝わっている、というのはよくよく起こりますし。
転送先の1つがたまたま不調だったりスプールが溢れてたり。もしくは、転送先の1つを廃止したけどめんどくさくて放置してあったり、卒業後、1年したら自動で廃止されるというルールの大学のメアドなんかで、忘れた頃にエラーになったり。
受信者側の問題ではあれ、トラブルは予想されてしかるべき運用でしたね。
良くあるのは、別コメントにもありますが転送設定がらみですね。あるアドレスにメールを送信→受信者側の設定で2つのアドレスに転送→そのうち1つのアドレスで受信エラーって場合に、混乱が発生します。
ポストアドレス☆( http://postadd.jp/ [postadd.jp] )の有料サービスでbizアドレスという機能を介すると、メール転送がらみのエラーが吸収されるから助かるよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
どこも (スコア:5, 参考になる)
会社の一斉メールでエラーが返ってきやすいのは、ドコモのアドレスですね。
しかもタチが悪いのは、エラーが返ってくるのに相手に届いているという、今回の問題とよく似た状況。
Re:どこも (スコア:5, 参考になる)
docomoに複数宛先を指定した時に、1件でもPC受信を拒否した宛先の人がいると
該当宛先に対するRCPT TOの後にエラーが返るのではなくDATAの後にエラーが返る。
よって、誰に送信できて誰に送信できなかったかを判断するのは送信側では不可能。
RFCに非準拠と公式に回答。
対策としては、自ネットワークのMTA側でdocomoのときのみ1通ずつ送るようにするしかない。
if [ $rcptdomain -eq "docomo" ];then
的な処理を・・・入れる
結構有名な話ですよね？
Re:どこも (スコア:4, 参考になる)
公式サイト上で「一旦メールを受信した後にエラーメール (NDR) として返信する場合もあります」と明言してますし。
Re:どこも (スコア:3, 興味深い)
そうだとすると応募者側の身から出た錆と言えなくもない気がしますが。
Re:どこも (スコア:3, 興味深い)
この件、気になって情報を集めていたんですが、
公式サイトの応募要領のPDFによれば
( http://www.sotetsu.co.jp/news_release/pdf/140707_01.pdf [sotetsu.co.jp] )
単に応募用紙に電子メールアドレス等を書かせて、指定された場所の応募BOXに投函し、
当選メールを待つというスタイルのようです。
メールで当選を知らせること自体はよくあることですが、迷惑メールフィルター等が
受信エラーを起こさないように、送信元のアドレスを知らせる等の
案内をしているものも多く、そのような配慮は恐らくなかったと思われるこの応募スタイルでは
応募者の過失を問うのは到底難しいのではないでしょうか。
そもそも受信エラーなんてどんな条件で出るかわからないしなぁ。
Re: (スコア:0)
エラーメッセージを読まなかったり、再送したり返信を促すメールを送らずにリストから除外って感じなんですかね…
Re:どこも (スコア:1)
転送設定の間違いで宛先(転送先)に届かず、エラーメールが返るというのであればまだしも、
今回の場合は宛先に届いているにも関わらずエラーメールが返っている、というのが問題なのでは。
確かにドコモはCcやBccで複数のアドレスを設定すると、ランダムでエラーになることがありますね。
Re:どこも (スコア:4, すばらしい洞察)
１つの宛先でforward複数している場合もありえるから、エラーが返ったら絶対に届いてないと思うのは解釈が間違ってる。
>今回の場合は宛先に届いているにも関わらずエラーメールが返っている、というのが問題なのでは。
Re:どこも (スコア:1)
自業自得にせよ、エラーメールは確定情報として扱うには怪しすぎますね。
この場合なら、届いたメールに書かれたURLにアクセスしたら当選が確定とかそういう運用にしとかないと。
複数の転送先が指定してあるアカウントで、その内の1つがエラーを返したけど、
他のアカウントでは無事に届いて居るので内容は伝わっている、というのはよくよく起こりますし。
転送先の1つがたまたま不調だったりスプールが溢れてたり。
もしくは、転送先の1つを廃止したけどめんどくさくて放置してあったり、
卒業後、1年したら自動で廃止されるというルールの大学のメアドなんかで、忘れた頃にエラーになったり。
受信者側の問題ではあれ、トラブルは予想されてしかるべき運用でしたね。
Re: (スコア:0)
良くあるのは、別コメントにもありますが転送設定がらみですね。
あるアドレスにメールを送信→受信者側の設定で2つのアドレスに転送→そのうち1つのアドレスで受信エラーって場合に、混乱が発生します。
Re: (スコア:0)
ポストアドレス☆( http://postadd.jp/ [postadd.jp] )の有料サービスでbizアドレスという機能を介すると、メール転送がらみのエラーが吸収されるから助かるよ。