You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
My PfGnyPGContext does nothing, besides returning the password, and the GetEncryptionKeys simply returns an IEnumerable<MailboxAddress>
When I de-encrypt that Multipart in the other end, then it has changed the 'Content-Transfer-Encoding' of MimeEntities inside the original Multipart I am encrypting, almost regardless of what I set it to. Somehow, the transfer encoding for individual MIME entities inside my Multipart ends up as "quoted-printable", even though I set it to "7bit", "8bit", "binary" or anything, EXCEPT if I set it to "base64", at which point it "respects my choice".
The funny thing is, if I sign my Multipart before I encrypt it, for then to encrypt the resulting Multipart from the signing process, does not create a "default Content-Transfer-Encoding" for me. But anything else, it overrides my choice of transfer encoding for individual entities, and creates a default value ...
I've tried changing my Content-Type for my multipart as a whole to see if that makes any difference, and it doesn't. I've tried "multipart/mixed" "form-data", and even "signed" to see if that's what's causing it, but the only thing that makes it respect my choice of transfer encoding for my individual entities, seems to be signing the message before I encrypt it ...
I am probably doing something wrong myself here, but it would be nice to understand exactly what that is ... :)
Thx,
.t
The text was updated successfully, but these errors were encountered:
BTW, when I construct the individual MimeEntities which I stuff into my Multipart which I later encrypt, I am not using the ContentTransferEncoding property directly, but rather MimeEntity.Headers.Replace.
My guess is that it's either the above fact, or that "GetBestEncoding" doesn't check if the header is already set ...
It looks like I accidentally copied that logic from MultipartSigned.
multipart/signed needs to "armor" the content of child MIME parts because it needs to prevent MTAs and MDAs from altering the message (trimming white space from the end of lines, folding long lines, mangling lines that begin with "From " to ">From ", etc.).
Howdy,
So I've got this bugger;
My PfGnyPGContext does nothing, besides returning the password, and the GetEncryptionKeys simply returns an IEnumerable<MailboxAddress>
When I de-encrypt that Multipart in the other end, then it has changed the 'Content-Transfer-Encoding' of MimeEntities inside the original Multipart I am encrypting, almost regardless of what I set it to. Somehow, the transfer encoding for individual MIME entities inside my Multipart ends up as "quoted-printable", even though I set it to "7bit", "8bit", "binary" or anything, EXCEPT if I set it to "base64", at which point it "respects my choice".
The funny thing is, if I sign my Multipart before I encrypt it, for then to encrypt the resulting Multipart from the signing process, does not create a "default Content-Transfer-Encoding" for me. But anything else, it overrides my choice of transfer encoding for individual entities, and creates a default value ...
I've tried changing my Content-Type for my multipart as a whole to see if that makes any difference, and it doesn't. I've tried "multipart/mixed" "form-data", and even "signed" to see if that's what's causing it, but the only thing that makes it respect my choice of transfer encoding for my individual entities, seems to be signing the message before I encrypt it ...
I am probably doing something wrong myself here, but it would be nice to understand exactly what that is ... :)
Thx,
.t
The text was updated successfully, but these errors were encountered: