それで、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.
U*IX, UN*X n. Used to refer to the Unix operating system (trademark and/or copyright AT&T) in writing, but avoiding the need for the ugly (tm) typography. Also used to refer to any or all varieties of Unixoid operating systems. Ironically, some lawyers now claim (1990) that the requirement for superscript-tm has no legal force, but the asterisk usage is entrenched anyhow.
Other parties frequently treat "Unix" as a genericized trademark. Some add a wildcard character to the name to make an abbreviation like "Un*x"[2] or "*nix", since Unix-like systems often have Unix-like names such as AIX, A/UX, HP-UX, IRIX, Linux, Minix, Ultrix, Xenix, Xinu, and XNU.
同報メール (スコア:3)
「16時になったら身の回りの片づけをお願いします」
というメールが来た。
その子に好意を寄せていた某君が
「〇〇ちゃん、いつも可愛いね。今度、お茶飲みに行きましょう」
といったメールを返した。
哀れななことに、女の子のメールは同報メールで、その返信は
全員に送られてしまった。
某君は次の人事異動のときに、それとなく別の部署に異動していった。
Re: (スコア:0)
口説きメールも痛いけど、
明らかにこいつらデキてるって感じのメールが流れてきた時には気まずいね。
間違える以前に (スコア:2)
こういう用途にBccを使う発想がおかしい。Bccはまとめて送るためのものではない。
というか、それ以前に、個人宛の手紙を「まとめて」送ろうなどという態度を改めるべきだ。
一通一通心を込めて個別のToで送れ。
まとめて送ることこそ複数Toの目的であり、複数ToやCcで送られるとまずい手紙ってのは、そもそもまとめて送られるべき手紙ではないのだ。
Re: (スコア:0)
だから :; を使えと大昔から言っているのに
運用がおかしいんじゃ? (スコア:1)
何で、500人のアドレスを列記したTo:を受け入れるシステムなんだろう?
添付データとかと比べれば、巨大なヘッダもスループットには影響しないだろうけど、展開して個別送付する部分の能力が無駄に大きい感じ。メーリングリスト用エンジンの流用かな?
そもそも、送られる方も、500人列挙のヘッダが来ても平気なんだろうか?
なんか、普段から、何処か外れた運用をしてるような気がする。
-- Buy It When You Found It --
Re:運用がおかしいんじゃ? (スコア:1)
> 展開して個別送付する部分の能力が無駄に大きい感じ。メーリングリスト用エンジンの流用かな?
ここの部分は、BCCでも同じじゃない?
Re:運用がおかしいんじゃ? (スコア:1)
システムに加えて、利用者側にも制限が必要かも。
メールの利用開始後一定期間は、組織内のメールアドレスにしか送信できないとか。
# 慣らし運転期間
-- う~ん、バッドノウハウ?
Re:運用がおかしいんじゃ? (スコア:2)
Re: (スコア:0)
運用おかしいのは同意だけど、多分システムだのは入れてなくて普通にメールクライアントで送っただけなのかと。
Re: (スコア:0)
>何で、500人のアドレスを列記したTo:を受け入れるシステムなんだろう?
あえて制御してなきゃ受け入れるのが基本でしょうね
>何で、500人のアドレスを列記したTo:を受け入れるシステムなんだろう?
全然平気です。大きくても30Kくらいですね。
>なんか、普段から、何処か外れた運用をしてるような気がする。
TOにメールアドレスを入力して送信するってメールの基本運用方法だと思います。
問題は個人情報保護ルールがあってそれを守る必要があったかどうかで。
Re:運用がおかしいんじゃ? (スコア:1)
>全然平気です。大きくても30Kくらいですね。
ああ、サイズ的には楽に処理出来ちゃいますね。
でも、30kBのデータは一覧不能ですよね。
>TOにメールアドレスを入力して送信するってメールの基本運用方法だと思います。
ここで、500人入れると絶対に宛先確認が不完全になる事が保証されちゃいます。
本来は、To:フィールドは一目で確認出来るサイズに制限し、それを超える場合は適切な代替作業を用意するべきで、その為のシステムが必要な筈です。
でも、そんなの組む金が無いから、人力作業を増やしてるんだろうなぁ。
-- Buy It When You Found It --
Re: (スコア:0)
おそらく全員に送るんだからTOに入れるっていう初心者がやりがちなミスだと思う
BCC何それ?何に使うの?っていうレベルな人が担当だったのではと・・・
メールを仕事で扱うならTO・CC・BCCの違いと使い方を覚えておくべきなんだよね
Re:運用がおかしいんじゃ? (スコア:1)
そもそも、BCCに大量に記述するのも変だろ。
ちゃんと個別に送るべき。
Re:運用がおかしいんじゃ? (スコア:1)
メールサーバーに何度も接続する時間がムダ。
とくに、接続に時間がかかる場合は。
Re: (スコア:0)
調べてみた。
というわけで、デフォルトで放置しておくと500人は通ってしまうかも。
Re: (スコア:0)
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.
Re: (スコア:0)
適当なこと書かずに、もう少し調べてから書いたほうが良いかと。
指摘されている設定はEnvelopeに係る設定の話ですよね。
大抵の場合は、送信側である程度のRCPT数で分割されちゃいます。
例えば、Postfixがメールを送信する場合、smtp_destination_recipient_limitが
初期値50に設定されている事が多いので、1通のメールで1000件の宛先を入れても、
Envelope的にはRCPTが50件入った20通のメールに分割して送信します。
よって、受信側でsmtpd_recipient_limitで制限しても
元々複数のメールに分割して送られてくるので
1000件でも10000件でも通ってしましますよと。
勘違いしたまま設定されている例が多いので・・・
Re:運用がおかしいんじゃ? (スコア:1)
# セキュリティ修正に1年かかるとかあるし
確認でき状態 (スコア:1)
仕事で使っている内製らしいメールチェッカーですが。
送信ボタンのした後に、to,cc,bcc,添付ファイルのチェックリストが出て一々確認しないと送信できなくなってた。
500人分のアドレスを確認するのは骨だろうけど、個人情報流出させること思えばそれくらいは頑張れそう。
コンサル様がそういうアドイン探すか作らせるかして入れないとダメかも。
#毎回のチェックがめんどくさい時はメールアドレス並べたaliasを作っておいて、それで送信。
Re:確認でき状態 (スコア:2)
昔の職場では、アドレスグループというかaliasで入力したばあい
手動で展開、確認できるよう変更されてた(Notes)
#サーバー側管理のものだけじゃなく個人のアドレス帳でもグループ作れる
#こいつのメンテは各個人になる
ところでいちいち入れられないとかいっているようだけどalias機能って
30年以上前からあるはずなんだが
#FOMAな携帯でもグループがある
>#毎回のチェックがめんどくさい時はメールアドレス並べたaliasを作っておいて、それで送信。
今回のはBcc指定しなければならないところをToだかCcにAliasほうりこんでしまった事故では
#散々聞いた事がある。Toなどに使えないようにすると不便が過ぎる
BCCの使い方 (スコア:1)
「一斉にメールを送りたいけど、受け取った人は互いに分からないようにする」
という目的にBCCを使うというのが、そもそも本来の使い方ではない
もう浸透してしまったから仕方ないけど
Re:BCCの使い方 (スコア:1)
本来は、正式の受信者として誰宛に送ったかを示すのがTo:、参考までにコピーを送るのがCc:、コピーを送るが、誰に送ったか見せたくないのがBcc:という用途が決まっていて、受け取った方はそれを見て判断する。それに従うべきなんですよ。
それで、To:に書いてあるけれど、それでも誰に送ったかを見せないようにするための標準的なやり方もあります。RFC 5322 Internet Message Format [ietf.org]のpp. 16-17, 3.4 Address Specificationのgroupの項。
ここで、group-listというのがアドレスの並び、display-nameというのは、アドレスではない単語の並び。そして、mailbox-listは省略可能。この方式の本来の使い方は、こんな感じ:
それで、宛先アドレスを隠したい場合は、たとえば
という風に表記して、送り先を見えないようにするというのが、標準に適合した正式のやり方です。
本当は、クライアントでチェックボックスでも作って、この方式を選べるようにするというのがいいのですが、誰も実装していないのが問題。
これだけ問題になっているというのに、まったく対策をとらないなんて、信じられないけど。
# RFC 822 → 2822 → 5322ね。追いかけるのが疲れる。
Re:BCCの使い方 (スコア:1)
ああ、せっかく日本語で例を書いたんだから、2つ目も日本語にすればよかった。こんなふうに:
Re:BCCの使い方 (スコア:1)
すまん。間違えた。
の、mailbox-listは、group-listの間違い(2822から5322で変わったんだよ!)。
そこは (スコア:1)
おわびメールで更にやらかしてくれないと…
the.ACount
むかしマイクロソフトもやらかしてた (スコア:0)
その頃働いてたゲーム会社でXBOX初代の説明会に申し込んだら返答がBCCじゃなくてTOで来たので「なるほど、あそこもXBOXやりたいのねー」とちょっと盛り上がったのを思い出した(もう時効
Re: (スコア:0)
あるヘルス嬢もやってしまったな
メールアドレスの変更のお知らせだったのが不幸中の幸い
Re: (スコア:0)
何それ?
突然来るアドレス変更のお知らせなんて詐欺かスパムなんじゃないの
捨てメアドは大事 (スコア:0)
こんな時の為の捨てメアド
個人情報を欲しがるSNSは信用してはならない
Re: (スコア:0)
急にSNSとかなにいってんの
Re:捨てメアドは大事 (スコア:1)
しくじった
奈良
市
Re: (スコア:0)
信用・ならぬ・市役所、でSNSなのかもしれない
今後、増えそうな予感 (スコア:0)
スマホしか使えない世代が増えてくると、こういうのを事前に防ぐシステムにしとく必要あんね
Re: (スコア:0)
うちは未だにBCC:って何?ってレベルですわ。
全てTO:にぶち込んで、よく問題にならないもんだ。
いまだに改善されない一斉送信のUIが悪い (スコア:0)
BCCやCCを使いたいときは文章で書かれたチェックボックスを押すようにしよう。
【To送信先入力欄】
□このメールを複数の宛先に同時送信する(BCC) □同時送信された全ての送信先アドレスを送信先に表示する(CC)
【CC,BCC送信先入力欄】
こんな感じで。(□はチェックボックス)
BCCがデフォルト、CCは必要な時明示的にチェックを入れるようにし、先にBCCをオンにしないと押せないようにする。
BCCとCCの併用はソフト側で禁止し、CCが必用なら別途送信させる。
少なくともデフォルトをBCCにする、CCをUI上一段下へ隠すのがメールソフトで当たり前になってほしい。
Re:いまだに改善されない一斉送信のUIが悪い (スコア:1)
> BCCとCCの併用はソフト側で禁止し、CCが必用なら別途送信させる。
いやいや、大量メールを普通のMUAで送ろうとするほうがおかしいんで、
(そういうの、キャリアにスパマー扱いされて止められたりするから)
ちゃんと配信システム使おうよ、ということでしょ。
BCCとCCの併用ができないと、他部署からの比例なメールが自分の部長のCCで来たとき、こっそりBCCに相手の本部長を入れて、丁寧な反論を返す、とかできないじゃないか。
Re: (スコア:0)
個人的にUnix系をワイルドカード使って省略する人って苦手
Unix使ってる俺カッケーアピールやめてください
こっちまでそういう目で見られる
Re:Windows厨は、MLとは何で、どういう時に用いるのか理解できない (スコア:1)
*nixだとLinux、BSD、Mach、MacOS、Solaris、illumos、Hurd、QNXどれにもヒットしないよなぁ
ヒットするのって○○Unix以外だとMinixとXENIXとPANIXくらい?
Re: (スコア:0)
それ以前に、正規表現の構文エラーだよね。
/.+nix/ じゃないと
多分、ワイルドカードを知ったばかりで「すごーい。かっこいー。つかいたーい」という感覚なんじゃないかな。
Re:Windows厨は、MLとは何で、どういう時に用いるのか理解できない (スコア:2)
*nix の他に、UN*X やU*IXって表現もありますが、こういったワイルドカード表記は、元々は「商標問題を避けるため、UNIXを伏せ字表現する」ために生まれたものですよ。元々は UNIXライクなOSはなんでもかんでもUNIXと呼んでいた状況から、AT&TがUNIXを商標登録して正統UNIXじゃないものをUNIXと呼ぶなとクレームがくるようになったために生まれた言葉。
1990年の Jargon File [jargon-file.org]
Wikipedia Unix-like [wikipedia.org]
って感じ。だから、*nix って表現を使うのは「ニワカ」ではなく、むしろ「おっさん」。
#Xが特徴的なので、Xは伏せ字にせずに、「UN*X」「U*IX」「*NIX」が使われるって感じですかね。まあ、「UNI*」でいけるのは「UNI+」ぐらいか。
Re:Windows厨は、MLとは何で、どういう時に用いるのか理解できない (スコア:1)
Re:Windows厨は、MLとは何で、どういう時に用いるのか理解できない (スコア:1)
> Linuxは厳密にはPOSIXに適合してないんだよなあ。
MacOS と Windows は準拠しているらしいのに。
つまり Mac, Windows, Linux の中で Unix じゃないのは Linux だけということか。
Re: (スコア:0)
ウインドウズのエクスプローラーの検索機能だとこれで通る
Re: (スコア:0)
ワイルドカードは正規表現がないころからあるんだから、頓珍漢な指摘だと思う。
Re: (スコア:0)
いやだから、To:にリストアドレスを書けば返信がまたそのリストを通じて配布されてしまうだろ。
Bcc:運用だろうが目的に適っていれば問題ない。
生半可にわかったつもりのお前みたいなのが一番あぶない。
#Bcc:はBcc:ヘッダに名前が載ると思ってるだろ?
Re: (スコア:0)
Reply-To:をどこにするかの設定次第かと。MLの投稿者に返信させるようにもできますから。
Re: (スコア:0)
ほぅ、お前のMUAはToに返信が返るのか。
そんな実装のMUAを教えてくれ。
ってか、権限設定すればいいだけだからねw
Re: (スコア:0)
いや、Exchangeだってエイリアスくらい普通にあるからね? 鼻の穴膨らませて語るほど大した技術じゃないからね?
あと、単発のキャンペーン企画で、参加者全員宛てのメール送るなんて多くても2~3回程度だからね?
キャンペーンの実施部著はユーザー部門だし、担当者はエンジニアじゃなくて普通の従業員だからね?
そんなケースでいちいちメーリングリストのシステム立ち上げて自動化するとかありえないからね?
Windowsかどうかなんて何の関係もないからね?
あなたには、もうちょっと広範囲のITのスキルと、ITコミュニティ以外の社会経験が必要なように思える。
Unixのコミュニティでは、あなたのような見識の狭いうぬぼれ屋が甘やかされる傾向にあるけど、自戒したほうが良いよ。
Re:Windows厨は、MLとは何で、どういう時に用いるのか理解できない (スコア:1)
Exchangeのエイリアスは実装が中途半端すぎてなぁ・・・
少なくともメーリングリストとしては使えないし、
メールヘッダのFromを適切に書き換えてくれない割に
エンベロープのMAIL FROMのみ書き換えるもんだから、トラブルになりやすい。
なお、UNIX/LinuxのエイリアスはExchangeのエイリアス以下の機能しか無い。
エンベロープすら書き換えないので、外部のユーザからのメールなどは
適切に設定されたSPFに引っかかる。
# 内部だけで使う分には手軽だし問題ない。
もちろんmailmanやSympaはフル機能なので申し分ないけども。
Re:Windows厨は、MLとは何で、どういう時に用いるのか理解できない (スコア:2)
シェア