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 @ domain1.com>
S: 250 OK
C: RCPT TO:<user2 @ domain2.com>
S: 250 OK
C: RCPT BCC:<user3 @ domain3.com>
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.
--
HLS