Hector,
Three very quick observations about this:
(1) Doesn't work end-to-end. If any relaying is involved, the
odds that the relay knows enough about the delivery server to
reliably make this commitment on its behalf are not high.
(2) For a number of technical reasons, I'd recommend thinking
about parameters or a separate command rather than changing the
"TO" argument to something else. If nothing else, the extension
model has been extensively tested for parameters and new
commands and is basically fail-safe. I don't have any reason to
believe that one could change "TO:" or "FROM:" in the RCPT or
MAIL commands without encountering new and quite interesting
bugs in one system or another.
(3) IMO, we need to keep in mind that every extension has costs.
While Robert has explained what he is trying to do, no one has
offered a persuasive argument that it is important enough to
justify trying to change huge numbers of MUAs and MTAs to make a
heuristic that would work slightly better in some cases. In
particular, a command variation would not help the recipient
determine the difference between "no intentional BCC" and
"sender doesn't support this mechanism for telling the recipient
that a BCC is present". One could improve that situation by
having the sender use a MAIL parameter with semantics of "if
there are BCCs among the recipients, I promise to tell you" as
well as the RCPT parameter (or other option) but it is
questionable whether even that would make this valuable enough
to be worth the effort.
best,
john
--On Wednesday, May 23, 2012 10:06 -0400 Hector Santos
<hsantos(_at_)isdg(_dot_)net> wrote:
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.