To:欄を使ったプライバシポリシ変更通知メールの一斉送信でメールアドレス漏えい 40
ストーリー by hylom
原因としてはよくあるものなのだが 部門より
原因としてはよくあるものなのだが 部門より
広告やスクリプトによるユーザー追跡をブロックするツールを提供しているGhosteryが、複数の顧客に送信するメールにおいて送信先メールアドレスをBcc:ではなくTo:で指定するというミスをしてしまったようだ。その結果、多数のメールアドレスが記載されたメールが顧客に届く事態となった（BleepingComputer、ScanNetSecurity）。
一括送信メールでBcc:ではなくTo:を利用してしまったためのトラブルはよく聞く話ではあるが、今回の件は送信されたメールが欧州の一般データ保護規則（GDPR）対応のための個人情報ポリシー変更通知メールであり、メール内には個人情報保護のための対応を済ませたなどと記載されていたことから話題となっている。
このメールはなんらかのバッチ処理で送信されたようで、各メールのTo:欄には500件のメールアドレスが入力されていたという。Ghosteryはこれに対し人的ミスだったとして謝罪した。
BCCでもおかしいでしょ (スコア:0, すばらしい洞察)
いったい誰がそんなおかしなメールの送り方を勧めてるんだ？
Re: (スコア:0)
1件ずつto:で送ればご満足いただけますか。
% cat list | xargs -i{} xmail -r support@ghostery.com -s "Privacy policy change notice" {} ＜ cat ./noticeletter
Re: (スコア:0)
契約なんかの建前としては個別の対応だからね。
今回のようなのを防ぐためにも1件ずつ送るべき。
Re: (スコア:0)
満足とかじゃなくて当たり前じゃね
Re:BCCでもおかしいでしょ (スコア:1)
うちだと宛先多数の場合はbccで送信しその旨表記してた。
toでもbccでも受け取る情報は同じだし
でも、結局リストを食わせて投げるなら。
toで送れば、一件ずつ対応してくれていると思って満足してくれる人がいるらしいのでその方が良いのか。
Re: (スコア:0)
満足どうこうじゃなく、そもそもの意味が違うでしょ。
TOなら主たる宛先として送られてきた、BCCなら別の人宛てに送ったものの控えを参考情報として送ってきた意味になる。
宛先の指定によって振り分けルールが組まれていることもあるし、きちんと意味の通り指定しないと相手の目に触れないことさえある。
Re:BCCでもおかしいでしょ (スコア:1)
＞TOなら主たる宛先として送られてきた、BCCなら別の人宛てに送ったものの控えを参考情報として送ってきた意味になる。
へーそうなんだ、ヘッダ内での自メールアドレス位置でメールの受け取り方変えるんですね。
Re:BCCでもおかしいでしょ (スコア:1)
ちょっとおもしろそうなので、設定してみようとした。
今の会社で使っている Outlook の仕訳ルールで
□ [宛先]に自分の名前がない場合
□ [CC]に自分の名前がある場合を除く
のチェック入れてみたけど、ML経由で送ってこられるやつには無力そうだった orz.
参加してるML全て登録は・・・ 把握してない、たまに勝手に追加されてるので諦めた。
プライベートで使ってるGmailでやろうとしたけど・・・わからなかった。
Re: (スコア:0)
> プライベートで使ってるGmailでやろうとしたけど・・・わからなかった。
gmailは検索クエリでフィルタを作れるから、CCやBCC別の検索ができればなんとかなるかな？
宛先別検索は「to:(メールアドレス)」で、「cc:(メールアドレス)」「bcc:～」「-cc:～」「!cc:～」みたいな指定でも検索が出来る。
toでの検索はccを含むっぽいからそれを踏まえた上でフィルタの適用順序とラベルフィルタを駆使すればどうにかなるはず。
> へーそうなんだ、ヘッダ内での自メールアドレス位置でメールの受け取り方変えるんですね。
TOとCCの使い分けってそれ以外に使い道ないんじゃない？
その意味では本人以外に名前を伏せれるのがBCCだけってのが半端なんだよね…BTOも寄越せ。
Re: (スコア:0)
Bccだとしても、フツーはある程度身内だと判って居る時の対応だろ。
Re: (スコア:0)
宛先１つに対して１通送るのと、BCCで５００つに対して１通にするのと、受け取る側には何の違いがあるの？
人的負荷はもちろん、メールサーバにも割と厳しい負荷がかかるんだけど。
「何か嫌だ」が理由で、５００倍の手間と負荷をかけさせないで欲しい。
Re:BCCでもおかしいでしょ (スコア:1)
To もしくは CC に自分のアドレスがあるかないかで，フィルタリングしたり，スパムフィルタのレベルを切り替えることって，クライアントレベルでもサーバレベルでも珍しくない運用だと思うんだけど（いわゆる「自分宛以外のメールの受信拒否」設定）．
だから，相手により見てもらいたい場合は To で送るようにマニュアルで決めているけど．
Re: (スコア:0)
Toが見なければいけないメールでCcが確認程度なんだからBccなんか見るわけ無いじゃない。
送信側の負荷なんて、時間掛けたり分散したりすれば済む話でしょ。その先の負荷は変わらないんだから。
Re: (スコア:0)
BCCを見れるの？
というか、差出人で判断しないの？
そして「時間かけたり」って、例えば1秒に1通だとすると、丸一日かけても86,400通しか送れないんだけど。
想像力足りなさすぎない？
# こういう連中が、無駄な仕事を増やしてるんだろうな……。
Re: (スコア:0)
最初のMTAに送るのに何で一通1秒もかけるの？
大量送信が必要ならそれ用のシステムを使うんだから、ユーザー側は一気に送ってその後の配送バランス調整は気にする必要もないでしょ。
Re: (スコア:0)
する必要がないというか、そういうおかしなフォーマットのメールは大抵スパムフィルタが弾く。
Re: (スコア:0)
MTAの処理でメール1通ごときに1秒かかると思ってるのも大概だし、パラレルでやるって発想がないのもアレだし、BCCのメールでも受取人全員が相手にすると思ってるし、差出人何か簡単に偽装できるから信用しないやつもいるって想像力が無いやつが何いってんだ？
Re: (スコア:0)
ToにもCcにもなければBccだろ。それ以外に送信先として設定できるヘッダがあるのかよ。
時間をかけるだけじゃなく分散しろとも書いてあるだろ。きちんと読め。
メールサーバーなんて一台のマシンに複数台構築できるほど負荷少ないんだから。
Re: (スコア:0)
> それ以外に送信先として設定できるヘッダがあるのかよ。
Delivered-To(転送先)とか。
転送元が転送時にToを変更しなかった場合、Toには自分への転送元のアドレスが入っているはずではあるので、
それを持って「自分(に転送が掛かっている)のアドレスがToにある」とは言えるのかな？
Re: (スコア:0)
今日、まさにコレをドヤ顔(死語？)でいってたやつがいた。
「(私忙しいんで)CCで来るメールは見てません(キリッ)」
と。
でもお前、Toでメールだしても反応鈍いし仕事も遅いしダメダメやん。と思ったのはナイショ。
＞Toが見なければいけないメールでCcが確認程度なんだからBccなんか見るわけ無いじゃない。
20世紀からメール使ってるし言いたいことはわかるけど、送る側にToとCCを厳密に区別する・できるスキルを期待している時点で甘い。
(期待できない環境にいます(泣 )
Re: (スコア:0)
俺なんかCCは当然としてTOに入ってても誰かやって的な内容なら容赦なく無視するぞ（どやぁ）
例外は会議とかで全員対象みたいな内容だけ
バイネーム以外は知らん、読まない
# だって取り敢えずで色んなプロジェクトのMLに入れるのやめてぇ……１日何百通とかおかしいでしょぉ……
Re:BCCでもおかしいでしょ (スコア:1)
＞色んなプロジェクトのMLに入れるのやめてぇ……１日何百通とか
単一のプロジェクトでは敵わなくても複数のプロジェクトが力を合わせると
linux-kernel@vger.kernel.org
に匹敵するかもしれない(数だけ勝負)という社会実験なのでしょう。
メテオフォール型開発のメテオ主になりさえすればいろいろ楽できる印象。
Re: (スコア:0)
これな。
中間管理職程度に偉い人ほどCCメールが頻発するせいで、自分がtoでないメールを別フォルダ、ひどい人だと自動的にゴミ箱に転送している人がいるんだよね。そのせいで弊社では、偉い人に読んでもらいたいメールは送信したあとに対面または電話で概要説明する、って文化が発生している。
ただわざとCCにして、読まれないことを期待しつつ承認をもらったふりして引き返せないとこまで既成事実を作るっていう最終手段がたまによく使えるので、下っ端としては痛し痒し。
ほんとに偉い幹部レベルはCCに秘書さんを入れて置けば、秘書フィルターによる優先度判断の上、紙に印刷してマーカ引いて幹部机においてくれるからまだ確実なんだよなぁ。ただ秘書さんへの出張お土産（なんと部門費で落ちる！）がかかせないけど。
Re: (スコア:0)
#3423808 です。
＞俺なんかCCは当然としてTOに入ってても誰かやって的な内容なら容赦なく無視するぞ（どやぁ）
でしょ。
メールの宛先の値がToかCCかって送り手が区別しても、読み手にとってはあまり意味ないってこと。
お偉いさんだろうがヒラだろうが、内容を判断してちゃんと反応する人はするし、
ToだろうがCCだろうが反応しない・できない人もいる。
(真に忙しすぎて読めないという人も含むけどそれは別の問題)
だから、送り手がToとCCを区別する意味(殆ど)なくて、送る側の自己満足と気休めと
「メールで送ってましたよね」という既成事実を作る用だと思ってます。既成事実づくりはたまに使います。
メールはちゃんと読んでくれる上司(但し忙しいと優先度が低下しちゃう)と、先に書いた
「(私忙しいんで)CCで来るメールは見てません(キリッ)」なヤツとか
「(私忙しいんで)忘れてました」なヤツとかが複数いる環境にいます。
上司がまともなんでマシな方ですかね。
Re: (スコア:0)
CCは当然としてTOに入ってても誰かやって的な内容なら容赦なく無視するぞ
Ccは無条件、Toは条件次第という違いがあるのに意味ないとはずいぶん乱暴な意見ですね。
そしてCcでは既成事実になりません。反応が欲しいならToに入れなさいって言われているじゃないですか。
惰性でCcに入れっぱなしにするのではなく、話が確定した時点でToに切り替えなさいよ。
Re: (スコア:0)
そもそもRFC的にはBCC送信先に送る内容に、他の複数のBCC指定を伏せるか否かは実装依存であり、保障されていない。
BCCなら送信先に、他の送信先リストが公開されないと思っていること自体が危うい。
Re: (スコア:0)
RCPTコマンドの内容を勝手にBCCとしてメールヘッダに追加するなんてサーバが経路上(特に各宛先MXサーバより手前だとやばい)に居たらそら漏れるけど、そういうヘンテコなサーバが居なけりゃメールヘッダ作るのはメーラーの仕事だし、わざわざBCCを伏せないメーラー使うほうが悪いとしか…
Re: (スコア:0)
そろそろEmailも仕様変更すればいいのにね。
こういう事故が度々起こるし、もうTo=BCC扱いでいいんじゃね。BCCは廃止。
送信先を共有したいときは手動でCCにすればいい。
Re: (スコア:0)
「スジ」の日本、「量」の中国
http://business.nikkeibp.co.jp/atcl/opinion/16/041100064/ [nikkeibp.co.jp]
を思い出させるスレ内容。日本人同士？だけど
漏れたのはGodaddyの社員とかQQの中国人とか本名使ったアドレスが多い (スコア:0)
https://img.devrant.com/devrant/rant/r_1432862_eaj9H.jpg [devrant.com]
Daniel SchwemmleinさんとかJu Siqueiraさんとかどうすんの?
RCPT TO (スコア:0)
何のサブミッションエージェントが使われたか分かりませんが、RCPT TO の内容が
他の受信者に知らされる事は無いと思います
すると推測としては、Thunderbirdとか普通の規模の送信を想定したエージェントを用いて
ToなりBccなりにアドレスを大量記載して送信したんでしょうねえ
Re:RCPT TO (スコア:1)
会社の規模を存じ上げませんが。
顧客にメールを送る際のガイドラインや手順が整備されていなかったのか、発送を請け負った人(下請け孫受けバイトさん？)が手近のメーラーから普段メールを送るやり方でやっちゃったんすかね。
顧客が500件 (スコア:0)
零細なのかな？
バッチ処理と言っても、
こういうことが起こるということは都度メーラーでメール作成してて、
送信だけバッチ処理してるということでは。
ポリシー変更の前にGDPRに対応できる運用整備をすべきだったな。
Re: (スコア:0)
いや、あて先が多すぎると配送経路で止められることがあるから、500個ずつに分割してるだけでしょ。
それでもメールの数が多すぎるから、バッチ処理したんだと思うよ。
Ghosteryが１０００万ユーロ払うとして (スコア:0)
アドレス暴露されたユーザは罰金からなにか払ってもらえるの？なにももらえないの？
Re: (スコア:0)
EUの完全勝利！また補助金バラまけるね
これが日本の情報リテラシー (スコア:0)
変なメールの送り方をするとフィルタに弾かれることすら知らない。
何が変なのかすら理解してない。
当たり前のようにBCCで～なんて言ってて頭おかしい。
Re: (スコア:0)
弾くのは受け取り側の自己責任なんで…
BCC以外にも黙って不達になる理由は山ほどある(受信者が無視するのを含む)から、受信確認が必須な用途は別でそれを確認しなきゃ駄目。
Re: (スコア:0)
メールサービスにフィルタリングが標準搭載だったりするので。
標的型攻撃も流行りだしているし、受け取ってもらえないようなメールは送信しないように気を付けないと。
#会社から依頼のあったマイナンバー登録のメールがフィッシング詐欺そのもののメールで笑った。
Re: (スコア:0)
だから「受信確認が必須な用途は別でそれを確認しなきゃ駄目」って言ってるじゃんか。
あらゆるフィルタリングに引っ駆らないテクニックなんて無い。あったらスパムがそれ使う。
正直BCCだからで機械的に弾く程度のフィルタにまともな対スパム能力があるとは思えない。
その程度で弾くなら誤爆も多いのが目に見えてるから、
弾いてもらってホワイトリスト登録を要求するほうがマシだろう。