https://bugs.kde.org/show_bug.cgi?id=356865
--- Comment #3 from Erik Quaeghebeur <kdeb...@equaeghe.nospammail.net> --- (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). -- You are receiving this mail because: You are watching all bug changes.
