I've looked at the code:

In src/Composer/Submission.cpp there is the function Submission::slotMessageDataAvailable that is responsible for creating the messages and saving them to the sent mail folder; it calls Submission::slotInvokeMsaNow() to send out the message. There is always an if-then(-else) to choose between sending the message ‘raw’ or using CATENATE (to add attachments). This function essentially (indirectly through MessageComposer::asRawMessage or MessageComposer::asCatenateData) calls the function MessageComposer::writeCommonMessageBeginning from src/Composer/MessageComposer.cpp to generate the header. In this function, the Bcc header is not included (as is appropriate for the version of the mail that is sent out).

So it seems that what would need to be done is to keep all the necessary data for the message in some variable, but not yet flattened to a single string. Then it can be flattened twice, including/excluding Bcc as appropriate, much later in the process. Does this seem like a good plan?

I may try my hand at a patch for this issue, but before starting, I need to have a good view of the architecture that seems appropriate to the maintainers.

P.S.: How the list of recipients to be passed to the MSA is created is still somewhat opaque to me, but my impression is that I won't need to bother with that.

> In this function, the
> Bcc header is not included (as is appropriate for the version 
> of the mail that is sent out).

Yeah, it seems that some MTAs out there (Exim is an example, [1]) do not 
strip out the Bcc headers during submission through ESMTP. Because Trojita 
tries to save bandwidth (see our support for BURL, CATENATE etc), there's a 
big value in only having to upload just one instance of an outgoing 
message.

It would be very easy to write out Bcc into the sent folder, but then we 
have to ensure that the Bcc is not leaked to the actual outgoing message. 
This is doable by, e.g., employing chunked message submission, where the 
composer remembers which part of the header contains this privacy-sensitive 
data, and white outs their content.

Here's how to do it:

1) Generate the plaintext of the message, place the Bcc header into a 
well-known place (end of all headers sounds like a trivial fix, if it's 
legal),
2) Remember the offsets of the beginning and end of this sensitive area,
3) Change the code to not treat the just-saved message as a single entity, 
but rather as a pair of (stuff before the whitened-out, stuff after), and 
pass this pair to BURL.

[1] http://marc.info/?l=mutt-dev&m=112930534206625

(In reply to Jan Kundrát from comment #2)
>
> 1) Generate the plaintext of the message, place the Bcc header into a 
> well-known place (end of all headers sounds like a trivial fix, if it's 
> legal),

It is legal to place Bcc at the end. It is also legal to place it at the top, which would result in only having to remember one offset, I think.

> 2) Remember the offsets of the beginning and end of this sensitive area,
> 3) Change the code to not treat the just-saved message as a single entity, 
> but rather as a pair of (stuff before the whitened-out, stuff after), and 
> pass this pair to BURL.

I have tried to wrap my head around the code, but I'm not there yet.

Orthogonal to that, I wonder whether it would make more sense to instead split the message in (header, body), have header+bcc and header. I guess that would essentially mean uploading the header twice, which may still be acceptable bandwidth-wise, and seems simpler and more generic (also applicable to other cases where the header should be different for the sent-out and for the stored version, e.g., Resent-Bcc, which cannot appear at the end of the header... although it could appear at the top).

Just for the record -- if you cannot get around the code in the src/Composer/ easily, it probably means that the code needs to be documented. Patches which add documentation are very welcome.

I have again been looking at the code. My current understanding is this:

There are 3 ways to send:
1. SMTP
2. BURL (SMTP)
3. IMAP (sending)

There are two ways to construct a message:
1. LOCAL
2. CATENATE

With message that have Bcc, we need to construct two messages, call them A(ppend) and S(ubmit).

* Case SMTP and LOCAL: locally create A and P, append A and plain-SMTP submit the S.

* Case SMTP and CATENATE: catenate-create/append A, locally create S (downloading A or parts thereof as needed?), plain-SMTP submit S.

* Case BURL and LOCAL: locally create A and P, append A and plain-SMTP submit the S. (BURL provides no shortcuts here?)

* Case BURL and CATENATE: catenate-create/append S, BURL-SMTP submit S, catenate-modify/append A from S, delete S.

* Case IMAP and LOCAL: locally create A and P, append A and IMAP-send S. (IMAP send provides no shortcut here?)

* Case IMAP and CATENATE: catenate-create/append S, IMAP-send S, catenate-modify/append A from S, delete S.

So, from the A and S-message construction point-of-view there are only three cases:

(SMTP or BURL or IMAP) and LOCAL, SMTP and CATENATE, (BURL or IMAP) and CATENATE

Is this analysis correct?

> Is this analysis correct?

I do not fully understand what the analysis means; the usage of "P" is 
unclear to me.

You're right in the big-picture sense -- there are indeed two possible 
varieties in "how to produce a representation of a message", the "let's 
build everything locally and produce a single blob" and a second "use a 
mixture if blobs and IMAP URLs".

Then there are several submission methods, and some can only use the 
"single blob" version of obtaining a message source.

If you're assuming that you need to expand these two versions to four 
versions because there's now a mixture of two booleans in the input:

1) do we require blobs of everything, or can we use IMAP URLs?
2) can we include the "private" parts (Bcc for now), or should we filter 
them out locally?

...then you're also right.

(In reply to Jan Kundrát from comment #6)
> 
> I do not fully understand what the analysis means; the usage of "P" is 
> unclear to me.

Sorry, P should be S.

Trojitá is no longer maintained, please switch to a maintained alternative like https://apps.kde.org/kmail2/

Sorry for the inconveniences.