cc:Mail Address Structures

The following message is a discussion of the issues involved in mapping the cc:Mail address fields into RFC822 addresses.

Date: Mon, 14 Nov 1994 21:15:27 -0700 (PDT)
From: Ned Freed <NED@XYZ.COM>
Subject: Re: PMDF 4.3 problems 

>I've received some reports from users of cc:Mail about Cc:'s being
>expressed as BCc:'s on messages coming to them via PMDF.  I currently
>have V4.3-7 on the system in question.

I'm fairly sure the reports are incorrect. Here is what is really happening.

Unlike every other mail system in the world (no, I'm not kidding about this -- cc:Mail is unique in this regard), cc:Mail maintains no clear distinction between envelope and header. Every other mail system has one set of addresses that are actively used to route messages (the envelope) and another set that are used to present originator and recipient information to the message recipient. The envelope undergoes constant change as the message is routed from one place to the next, but the header stays the same (modulo rewriting and encapsulation operations), which provides the recipient with a stable information base about who the message is from and who was sent to originally.

cc:Mail, on the other hand, blends the envelope and header. The result is that the end user is painfully aware of the transforms that are applied by message routing operations. There is simply no way to to know who the message was originally sent to with any certainty. This is an exceedingly poor design choice in my opinion, but like it or not it is how cc:Mail works.

More specifically, cc:Mail has the following kinds of addresses:

  1. To addresses representing active primary recipients.
  2. Cc addresses representing active secondary recipients.
  3. Bcc addresses representing active blind carbon recipients.
  4. *To addresses representing inactive primary recipients.
  5. *Cc addresses representing inactive secondary recipients.

The rest of the world has:

a. Active recipients (envelope).
b. Original primary recipient list (header).
c. Original secondary recipient list (header).
d. Original blind carbon recipient list (header).

Mapping between the two is a very imperfect process, governed by certain immutable criteria:

  1. Active recipients have to remain active. Failure to observe this condition causes messages to be lost.
  2. Inactive recipients have to remain inactive. Failure to observe this condition can cause duplication and message loops.
  3. Primary and secondary distinctions should be observed.
  4. Blind recipients cannot be revealed.

These criteria in turn lead to a very narrow range of legal mappings:

a maps to
1, 2, or 3, and 1 is only possible if the address is also in the b list, and 2 is only possible if the address is also in the c list.

b maps to
1 or 4, and 1 is only possible if the address is also in the envelope.

c maps to
2 or 5, and 2 is only possible if the address is also in the envelope.

d maps to
must be discarded, since there is no equivalent in cc:Mail.

The problem, of course, is that since the envelope has undergone changes due to routing it is simply not possible to correlate envelope and header information completely. No single agent ever has the knowledge to do this. The usual result is that envelope addresses end up in the Bcc list even when the same address (albeit in a completely different form) is in fact in the header. The corresponding header address then ends up in the *To or *Cc list.

This mapping is in fact exactly what PMDF implements. If you want to propose another scheme you are welcome to, but I should warn you that I've been over this dozens of times in hundreds of different contexts and the approach we use now really is optimal.

>Are you aware of such a problem, and if so, is there a fix available?

There is no "problem" other than the fundamental one of mapping between two incompatible systems. At present the only way to get a blind carbon recipient is when there's an envelope address that doesn't match anything in the header at all. This is undoubtedly where the blind carbon recipient you are seeing is coming from.

Search: