Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id SAA24382; Mon, 29 Sep 1997 18:21:08 -0400 (EDT) Received: by CS.UTK.EDU (bulk_mailer v1.7); Mon, 29 Sep 1997 18:21:00 -0400 Received: by CS.UTK.EDU (cf v2.9s-UTK) id SAA24347; Mon, 29 Sep 1997 18:20:59 -0400 (EDT) Received: from foxharp.boston.ma.us (gutso.american.com [204.253.111.241]) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id SAA24333; Mon, 29 Sep 1997 18:20:51 -0400 (EDT) Received: (qmail 837 invoked by uid 406); 29 Sep 1997 22:21:07 -0000 To: drums@cs.utk.edu Subject: Re: Bcc semantics In-reply-to: djb's message of 29 Sep 1997 20:15:02 -0000. <19970929201502.17980.qmail@cr.yp.to> Reply-to: pgf@foxharp.boston.ma.us MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <833.875571667.1@foxharp.boston.ma.us> Date: Mon, 29 Sep 1997 18:21:07 -0400 Message-ID: <835.875571667@foxharp.boston.ma.us> From: Paul Fox > > I'm curious about the history of the RFC 822 comment about keeping Bcc > in the copies sent to the Bcc people. What systems do this? Why? Bcc > certainly isn't a standard concept in physical memo headers. sure it is -- i think it's quite common for a physical memo to list the Bcc: recipients on their copies, otherwise they don't know why they got it (e.g. it wasn't by mistake), and it tells them the listed recipient doesn't know they got it. the electronic equivalent is to send a separate copy (separate envelope). it happens that in the electronic world of multiple-recipient envelopes you can also pull the trick of simply not listing the Bcc recipients in the headers, and their UA can intuit that it's a Bcc, but that's somewhat more dangerous in that it relies on a UA feature that may or may not be present. paul --------------------- paul fox, pgf@foxharp.boston.ma.us (arlington, ma)