[Top] [All Lists]

Re: "proper" handling of BCC

2012-05-23 09:21:04

Hector Santos wrote:

According to the TBIRD test, it stripped the BCC, and used one transaction (with two RCPT TO). I just did the test with OE, and the same happen.

Our PX MUA creates two messages, one with the special privacy note. I don't see off hand how this can be otherwise be done currently today without some new IETF MSA proposal that the source MUA is aware of. If its going to use a single transaction with multiple RCPT TO lines, the RCPT TO: needs an attribute or a new command - RCPT BCC: or something like that.

But the fact that its one transaction, to me, the design assumption by these MUA is that the backend is not expected to do anything here, and its doesn't expect the MSA to reconstruction the distribution list. That would be a major flaw here when it comes to the BCC.

Hmmm, I am just thinking, we can have a backward compatible method to support a RCPT BCC: command.

For example:

   C: MAIL FROM:< user1 @>
   S: 250 OK
   C: RCPT TO:<user2 @>
   S: 250 OK
   C: RCPT BCC:<user3 @>

Two responses:

   S: 250 OK - will MARK message.
   S: 500 command not understood

If the MSA provides a positive response, then the MUA is does not have to send a 2nd message. The MSA will add a special note and/or maybe add back the BCC to the header so that at least the end-point MUA will see the BCC in the mail view header display.

If the MSA provides a negative response, especially 500, then the MUA now knows it will need to send a 2nd transaction with a special note to the message or perhaps keeps the BCC in the header.

It all seems doable. The question I will consider is whether keeping the BCC in the special message only good enough for the end targets to realize it is special.


<Prev in Thread] Current Thread [Next in Thread>