パスワードを忘れた? アカウント作成
13310754 story
情報漏洩

奈良市、BCCとTOを間違えて507人分のメールアドレス流出 61

ストーリー by hylom
2017年にもなってまだこういうトラブルが 部門より
あるAnonymous Coward 曰く、

奈良市がメールを送る際に「Bcc:」と「To:」を間違え、ほかの登録者のメールアドレスが見えてしまうというトラブルが発生したとのこと(産経新聞)。

問題が発生したのは、同市が実施している健康キャンペーンの参加者に対して送信されたメール。事業に参加していた同課の職員の指摘で発覚した。これにより、メールの受信者が登録者507人の氏名やメールアドレスを確認でき状態になっていたという。その後、削除を要請するおわびのメールを送信したそうだ。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by NOBAX (21937) on 2017年06月15日 15時49分 (#3228480)
    昔、働いていた職場で、週末に事務の女の子から
    「16時になったら身の回りの片づけをお願いします」
    というメールが来た。
    その子に好意を寄せていた某君が
    「〇〇ちゃん、いつも可愛いね。今度、お茶飲みに行きましょう」
    といったメールを返した。
    哀れななことに、女の子のメールは同報メールで、その返信は
    全員に送られてしまった。
    某君は次の人事異動のときに、それとなく別の部署に異動していった。
    • by Anonymous Coward

      口説きメールも痛いけど、
      明らかにこいつらデキてるって感じのメールが流れてきた時には気まずいね。

  • by minet (45149) on 2017年06月15日 18時37分 (#3228643) 日記

    こういう用途にBccを使う発想がおかしい。Bccはまとめて送るためのものではない。

    というか、それ以前に、個人宛の手紙を「まとめて」送ろうなどという態度を改めるべきだ。
    一通一通心を込めて個別のToで送れ。

    まとめて送ることこそ複数Toの目的であり、複数ToやCcで送られるとまずい手紙ってのは、そもそもまとめて送られるべき手紙ではないのだ。

    • by Anonymous Coward

      だから :; を使えと大昔から言っているのに

  • 何で、500人のアドレスを列記したTo:を受け入れるシステムなんだろう?
    添付データとかと比べれば、巨大なヘッダもスループットには影響しないだろうけど、展開して個別送付する部分の能力が無駄に大きい感じ。メーリングリスト用エンジンの流用かな?
    そもそも、送られる方も、500人列挙のヘッダが来ても平気なんだろうか?

    なんか、普段から、何処か外れた運用をしてるような気がする。

    --
    -- Buy It When You Found It --
    • by nim (10479) on 2017年06月15日 16時41分 (#3228538)

      > 展開して個別送付する部分の能力が無駄に大きい感じ。メーリングリスト用エンジンの流用かな?

      ここの部分は、BCCでも同じじゃない?

      親コメント
    • システムに加えて、利用者側にも制限が必要かも。
      メールの利用開始後一定期間は、組織内のメールアドレスにしか送信できないとか。

      # 慣らし運転期間

      --
      -- う~ん、バッドノウハウ?
      親コメント
    • by Anonymous Coward

      運用おかしいのは同意だけど、多分システムだのは入れてなくて普通にメールクライアントで送っただけなのかと。

    • by Anonymous Coward

      >何で、500人のアドレスを列記したTo:を受け入れるシステムなんだろう?
      あえて制御してなきゃ受け入れるのが基本でしょうね

      >何で、500人のアドレスを列記したTo:を受け入れるシステムなんだろう?
      全然平気です。大きくても30Kくらいですね。

      >なんか、普段から、何処か外れた運用をしてるような気がする。
      TOにメールアドレスを入力して送信するってメールの基本運用方法だと思います。

      問題は個人情報保護ルールがあってそれを守る必要があったかどうかで。

      • >全然平気です。大きくても30Kくらいですね。
        ああ、サイズ的には楽に処理出来ちゃいますね。
        でも、30kBのデータは一覧不能ですよね。

        >TOにメールアドレスを入力して送信するってメールの基本運用方法だと思います。
        ここで、500人入れると絶対に宛先確認が不完全になる事が保証されちゃいます。

        本来は、To:フィールドは一目で確認出来るサイズに制限し、それを超える場合は適切な代替作業を用意するべきで、その為のシステムが必要な筈です。
        でも、そんなの組む金が無いから、人力作業を増やしてるんだろうなぁ。

        --
        -- Buy It When You Found It --
        親コメント
    • by Anonymous Coward

      おそらく全員に送るんだからTOに入れるっていう初心者がやりがちなミスだと思う
      BCC何それ?何に使うの?っていうレベルな人が担当だったのではと・・・
      メールを仕事で扱うならTO・CC・BCCの違いと使い方を覚えておくべきなんだよね

    • by Anonymous Coward

      調べてみた。

      • sendmail:「O MaxRecipientsPerMessage」で制御。デフォルトはディストリビューションに依ると思われるが、Wileyの『Red Hat Fedora Linux 2 Bible』だと「100」になっている
      • postfix:「smtpd_recipient_limit」で制御。デフォルトは「1000」
      • Exchange 2010:「msExchRecipLimit」で制御。デフォルトは「5000」

      というわけで、デフォルトで放置しておくと500人は通ってしまうかも。

      • by Anonymous Coward

        smtpd_recipient_limitはメールサーバがメールを受信するとき、1通のメールを何人まで配っていいのかを制限しているだけで、送信する方は制限できないのでは?

        以下のようにせよ、ただしBCCには無力と書かれた文書を見ますが。

        main.cfにヘッダのチェックを指定

        header_checks = pcre:/etc/postfix/header_checks

        header_checks ファイルに@の数を数える正規表現を指定

        /^To:([^@]*@){10,}/ REJECT Sorry, your message has too many recipients.
        /^Cc:([^@]*@){10,}/ REJECT Sorry, your message has too many recipients.

      • by Anonymous Coward

        適当なこと書かずに、もう少し調べてから書いたほうが良いかと。

        指摘されている設定はEnvelopeに係る設定の話ですよね。
        大抵の場合は、送信側である程度のRCPT数で分割されちゃいます。

        例えば、Postfixがメールを送信する場合、smtp_destination_recipient_limitが
        初期値50に設定されている事が多いので、1通のメールで1000件の宛先を入れても、
        Envelope的にはRCPTが50件入った20通のメールに分割して送信します。

        よって、受信側でsmtpd_recipient_limitで制限しても
        元々複数のメールに分割して送られてくるので
        1000件でも10000件でも通ってしましますよと。

        勘違いしたまま設定されている例が多いので・・・

  • by nemui4 (20313) on 2017年06月15日 15時53分 (#3228487) 日記

    仕事で使っている内製らしいメールチェッカーですが。
    送信ボタンのした後に、to,cc,bcc,添付ファイルのチェックリストが出て一々確認しないと送信できなくなってた。
    500人分のアドレスを確認するのは骨だろうけど、個人情報流出させること思えばそれくらいは頑張れそう。
    コンサル様がそういうアドイン探すか作らせるかして入れないとダメかも。

    #毎回のチェックがめんどくさい時はメールアドレス並べたaliasを作っておいて、それで送信。

    • by tenokida (42811) on 2017年06月17日 7時16分 (#3229454) 日記

      昔の職場では、アドレスグループというかaliasで入力したばあい
      手動で展開、確認できるよう変更されてた(Notes)
      #サーバー側管理のものだけじゃなく個人のアドレス帳でもグループ作れる
      #こいつのメンテは各個人になる

      ところでいちいち入れられないとかいっているようだけどalias機能って
      30年以上前からあるはずなんだが
      #FOMAな携帯でもグループがある

      >#毎回のチェックがめんどくさい時はメールアドレス並べたaliasを作っておいて、それで送信。
      今回のはBcc指定しなければならないところをToだかCcにAliasほうりこんでしまった事故では
      #散々聞いた事がある。Toなどに使えないようにすると不便が過ぎる

      親コメント
  • by Anonymous Coward on 2017年06月15日 18時20分 (#3228627)

    「一斉にメールを送りたいけど、受け取った人は互いに分からないようにする」
    という目的にBCCを使うというのが、そもそも本来の使い方ではない
    もう浸透してしまったから仕方ないけど

    • 本来は、正式の受信者として誰宛に送ったかを示すのがTo:、参考までにコピーを送るのがCc:、コピーを送るが、誰に送ったか見せたくないのがBcc:という用途が決まっていて、受け取った方はそれを見て判断する。それに従うべきなんですよ。

      それで、To:に書いてあるけれど、それでも誰に送ったかを見せないようにするための標準的なやり方もあります。RFC 5322 Internet Message Format [ietf.org]のpp. 16-17, 3.4 Address Specificationのgroupの項。

      group = display-name ":" [group-list] ";" [CFWS]

      (中略)

      group-list = mailbox-list / CFWS / obs-group-list

      (中略)

      When it is desirable to treat several mailboxes as a single unit (i.e., in a distribution list), the group construct can be used. The group construct allows the sender to indicate a named group of recipients. This is done by giving a display name for the group, followed by a colon, followed by a comma-separated list of any number of mailboxes (including zero and one), and ending with a semicolon. Because the list of mailboxes can be empty, using the group construct is also a simple way to communicate to recipients that the message was sent to one or more named sets of recipients, without actually providing the individual mailbox address for any of those recipients.

      ここで、group-listというのがアドレスの並び、display-nameというのは、アドレスではない単語の並び。そして、mailbox-listは省略可能。この方式の本来の使い方は、こんな感じ:

      To: ●●検討WGメンバー: 山田太郎 <taro@example.com>, 田中花子 <hanako@example.com>;

      それで、宛先アドレスを隠したい場合は、たとえば

      To: Undisclosed Recipients:;

      という風に表記して、送り先を見えないようにするというのが、標準に適合した正式のやり方です。

      本当は、クライアントでチェックボックスでも作って、この方式を選べるようにするというのがいいのですが、誰も実装していないのが問題。

      これだけ問題になっているというのに、まったく対策をとらないなんて、信じられないけど。

      # RFC 822 → 2822 → 5322ね。追いかけるのが疲れる。

      親コメント
  • by the.ACount (31144) on 2017年06月16日 12時48分 (#3229079)

    おわびメールで更にやらかしてくれないと…

    --
    the.ACount
  • by Anonymous Coward on 2017年06月15日 15時18分 (#3228443)

    その頃働いてたゲーム会社でXBOX初代の説明会に申し込んだら返答がBCCじゃなくてTOで来たので「なるほど、あそこもXBOXやりたいのねー」とちょっと盛り上がったのを思い出した(もう時効

    • by Anonymous Coward

      あるヘルス嬢もやってしまったな
      メールアドレスの変更のお知らせだったのが不幸中の幸い

      • by Anonymous Coward

        何それ?
        突然来るアドレス変更のお知らせなんて詐欺かスパムなんじゃないの

  • by Anonymous Coward on 2017年06月15日 15時26分 (#3228453)

    こんな時の為の捨てメアド
    個人情報を欲しがるSNSは信用してはならない

  • by Anonymous Coward on 2017年06月15日 15時47分 (#3228477)

    スマホしか使えない世代が増えてくると、こういうのを事前に防ぐシステムにしとく必要あんね

    • by Anonymous Coward

      うちは未だにBCC:って何?ってレベルですわ。
      全てTO:にぶち込んで、よく問題にならないもんだ。

  • by Anonymous Coward on 2017年06月15日 16時37分 (#3228534)

    BCCやCCを使いたいときは文章で書かれたチェックボックスを押すようにしよう。

    【To送信先入力欄】
    □このメールを複数の宛先に同時送信する(BCC) □同時送信された全ての送信先アドレスを送信先に表示する(CC)
    【CC,BCC送信先入力欄】

    こんな感じで。(□はチェックボックス)
    BCCがデフォルト、CCは必要な時明示的にチェックを入れるようにし、先にBCCをオンにしないと押せないようにする。
    BCCとCCの併用はソフト側で禁止し、CCが必用なら別途送信させる。

    少なくともデフォルトをBCCにする、CCをUI上一段下へ隠すのがメールソフトで当たり前になってほしい。

    • > BCCとCCの併用はソフト側で禁止し、CCが必用なら別途送信させる。

      いやいや、大量メールを普通のMUAで送ろうとするほうがおかしいんで、
      (そういうの、キャリアにスパマー扱いされて止められたりするから)
      ちゃんと配信システム使おうよ、ということでしょ。

      BCCとCCの併用ができないと、他部署からの比例なメールが自分の部長のCCで来たとき、こっそりBCCに相手の本部長を入れて、丁寧な反論を返す、とかできないじゃないか。

      親コメント
typodupeerror

あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー

読み込み中...