Arthur S. Alexion on Fri, 18 Apr 2003 18:43:04 -0400 |
An apology and a response: On Fri, 2003-04-18 at 15:08, Mark Dominus wrote: > > I just learned on the Evolution list that some servers add the header > > Apparently-to: identifying BCC recipients. > > I don't think that is true. Some servers (including Sendmail, I > think) add 'Apparently-To' to identify the *envelope recipient* when > there is no 'To' field in the message. Yes. After I sent this message, I learned that the problem only occurs where there is a BCC entry, but blank TO and CC fields. Ergo, The "visible" recipients, TO and CC don't exist to read the header and learn who else got the message. > > > > In Windows, I have always used Pegasus as my MUA. Pegasus sends out > > separate mails whenever there is a BCC, to insure security. I thought > > all MUAs did this. > > Even if they did do that, it would not 'insure security'. The > 'Apparently-To' field could be (and sometimes is) added by the remote > MTA. There is nothing to stop this MTA from adding a field that says > > Thought-you-might-like-to-know: Arthur Alexion also sent mail > today to Miss Audra Scarlett with subject > "CONFIDENTIAL: you left your underpants at my house" > > or whatever else it likes, regardless of whether the message was sent > separately from others or not. Here the remote MTA has helpfully > linked your message concerning the FY 2003 budget with an unrelated > one concerning Miss Scarlett's underwear. I suppose, in theory, one could develop an MTA that aggregated and summarized mail from a particular address or IP and sent out info on one message that was contained in another. But I've never heard of one which does, nor any reason to develop and distribute that capability since it would most likely have to be the sender's SMTP server to be effective (random other servers along the way may not get any other mail from that sender). But practically speaking, by splitting the copy intended for the visible recipients, you make it _almost_ impossible for any server other than the sender's SMTP server to "know" what was contained in any other message or who the other message was addressed. > > > Are the other Linux MUAs broken like Evolution? > > There is no officially recognized set of "Linux MUAs". There are > probably dozens of different MUAs that can be used with a GNU/Linux > system. So there is no way to answer this question without > enumerating the behavior of every one of the dozens of programs that > you might be interested in. Oh, come on Linux, Unix, Schmunix, you know what the topics of this list are, and that we often say Linux when we could mean BSD and other Posix-related systems. > > In any case I think you may be mistaken in assigning the blame to the > MUA here. I have learned since this posting that that is unquestionably the case. Hence, the "apology". > > For example, consider the 'qmail-inject' MUA. qmail-inject properly > removes the Bcc: line from the message before inserting it into the > qmail local queue. If there are three local recipients and three > remote recipients, there will be two copies of the message in the > queue, one for the local recipients and one for the remote > recipients. However, both copies will be identical. > > >From there, the qmail MTA will transmit the message separately to > every one of the six recipients. > > The remote MTA still might add naughty or scurrilous headers to the > incoming messages. This has nothing to do with qmail-inject. When speaking of the "remote MTA" are we speaking of the sender's SMTP server, the recipient's POP or IMAP server, or some random link along the way. I would think that the only one in a position to do mischief would be the sender's POP server, which presumably, the sender has some knowledge or control over. > > > Is it a flaw in the standard that permits this? > > That is a judgement call. I would say that it is not, that it is a > quality-of-implementation issue in the remote MTA. > > > In my work BCCs and their privacy are critical. It's a "don't use this > > software for serious work" issue. > > I hope this message contains specific information that makes it easier > for you to evaluate MUAs. Yes, thank you, along with some clarification from the original thread that caused my concern. -- Arthur S. Alexion <arthur@alexion.com> Arthur S. Alexion LLC _________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.netisland.net/mailman/listinfo/plug-announce General Discussion -- http://lists.netisland.net/mailman/listinfo/plug
|
|