I have the problem, that the content of some (signed only) e-Mails is not shown in Thunderbird. No matter if I enable auto-decryption or manually decrypt via the button.
Also no error or wrong signature message is shown.
Thunderbird without enigmail shows the e-Mail correctly,
also if I manually strip the signature from the e-Mail Thunderbird with enigmail will show the content correctly.
I can't find any wrong content in the e-Mail, so might it be an enigmail issue?
Tested on two different Win10 (1803) machines with Thunderbird 60.5.2 (32Bit), enigmail 2.0.9 and GnuPG 2.2.11 (gpg4win build)
There are two empty lines between the end of the inner part (multipart/alternative) and the following part (application/signature). These two empty lines are wrong, as they don't belong to any MIME part.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've also tried with one empty line (same effect, I can also create a test-message if you want to).
But eleminating both empty lines would break the RFC3156 https://tools.ietf.org/html/rfc3156#section-5
as it is statet there that any signed message (in this case the whole multipart/alternative part) has to end with <cr><lf>. Further the line break preceding the boundary of the signature part "is considered to be part of the delimiter" (See note). So there has to be one empty line for a RFC3156 conform signed message (two <cr><lf> are mandatory).</lf></cr></lf></cr>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've created a new e-mail reproducing this behavior and having only one empty line (same as enigmail creates the e-mails / th key is still the same).
Thunderbird is not showing the content.
But surprisingly the Thunderbird Windows-Notification is showing the content.
First of all, a preceeding CRLF does not mean an empty line, but just the end of a line. The RFC does not say that there must be an empty line, but only that the data to verify stops just before the CRLF.
In my eyes, the problem is that the RFC is not precise in this respect because a multipart/mixed message has a defined end (until the end of the final delimiter), and not beyond. And this collides with the definition of RFC 3156. I'll try some other mail clients to find out how they handle empty lines in this case. At the very end, we have to make sure that mail clients are interoperable and behave the same way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The RFC say "Note: The accepted OpenPGP convention is for signed data to end
with a <cr><lf> sequence. Note that the <cr><lf> sequence
immediately preceding a MIME boundary delimiter line is considered
to be part of the delimiter in [3], 5.1. Thus, it is not part of
the signed data preceding the delimiter line. An implementation
which elects to adhere to the OpenPGP convention has to make sure
it inserts a <cr><lf> pair on the last line of the data to be
signed and transmitted"
I do read it as it implies an empty line.</lf></cr></lf></cr></lf></cr>
Anyhow the Thunderbird/Enigmail generated e-Mails have those empty line and so do my, I think everything is fine on that point and has nothing to do with the interoperability.
As now again I have played around with this issue, I thought that enigmail may have problems reading the boundaries, perhaps problems with the search and the * character in the boundaries of my mail. And et voila replacing the stars in the boundaries made enigmail parsing the mail correct.
I don't know why this only happens with signed only e-Mails. I never have seen such behavior with combined signed/encrypted or only encrypted e-Mails.
It seems like there is a problem with the searching routine, maybe stating the stars as placeholders.
Last edit: Blacky 2019-02-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I actually found out that the number of empty lines is not the reason for the problem. If I replace the text in the boundary with something else (for example --inner and --outer) then the message is displayed correctly. I suspect that Enigmail has a problem with the "*" in the delimiter, but I'll need to check this.
👍
1
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I have the problem, that the content of some (signed only) e-Mails is not shown in Thunderbird. No matter if I enable auto-decryption or manually decrypt via the button.
Also no error or wrong signature message is shown.
Thunderbird without enigmail shows the e-Mail correctly,
also if I manually strip the signature from the e-Mail Thunderbird with enigmail will show the content correctly.
I can't find any wrong content in the e-Mail, so might it be an enigmail issue?
Tested on two different Win10 (1803) machines with Thunderbird 60.5.2 (32Bit), enigmail 2.0.9 and GnuPG 2.2.11 (gpg4win build)
Unfortunately, the message is not 100% correct.
There are two empty lines between the end of the inner part (multipart/alternative) and the following part (application/signature). These two empty lines are wrong, as they don't belong to any MIME part.
Thank you for the quick answer!
I've also tried with one empty line (same effect, I can also create a test-message if you want to).
But eleminating both empty lines would break the RFC3156
https://tools.ietf.org/html/rfc3156#section-5
as it is statet there that any signed message (in this case the whole multipart/alternative part) has to end with <cr><lf>. Further the line break preceding the boundary of the signature part "is considered to be part of the delimiter" (See note). So there has to be one empty line for a RFC3156 conform signed message (two <cr><lf> are mandatory).</lf></cr></lf></cr>
I've created a new e-mail reproducing this behavior and having only one empty line (same as enigmail creates the e-mails / th key is still the same).
Thunderbird is not showing the content.
But surprisingly the Thunderbird Windows-Notification is showing the content.
First of all, a preceeding CRLF does not mean an empty line, but just the end of a line. The RFC does not say that there must be an empty line, but only that the data to verify stops just before the CRLF.
In my eyes, the problem is that the RFC is not precise in this respect because a multipart/mixed message has a defined end (until the end of the final delimiter), and not beyond. And this collides with the definition of RFC 3156. I'll try some other mail clients to find out how they handle empty lines in this case. At the very end, we have to make sure that mail clients are interoperable and behave the same way.
The RFC say "Note: The accepted OpenPGP convention is for signed data to end
with a <cr><lf> sequence. Note that the <cr><lf> sequence
immediately preceding a MIME boundary delimiter line is considered
to be part of the delimiter in [3], 5.1. Thus, it is not part of
the signed data preceding the delimiter line. An implementation
which elects to adhere to the OpenPGP convention has to make sure
it inserts a <cr><lf> pair on the last line of the data to be
signed and transmitted"
I do read it as it implies an empty line.</lf></cr></lf></cr></lf></cr>
Anyhow the Thunderbird/Enigmail generated e-Mails have those empty line and so do my, I think everything is fine on that point and has nothing to do with the interoperability.
As now again I have played around with this issue, I thought that enigmail may have problems reading the boundaries, perhaps problems with the search and the * character in the boundaries of my mail. And et voila replacing the stars in the boundaries made enigmail parsing the mail correct.
I don't know why this only happens with signed only e-Mails. I never have seen such behavior with combined signed/encrypted or only encrypted e-Mails.
It seems like there is a problem with the searching routine, maybe stating the stars as placeholders.
Last edit: Blacky 2019-02-27
I actually found out that the number of empty lines is not the reason for the problem. If I replace the text in the boundary with something else (for example --inner and --outer) then the message is displayed correctly. I suspect that Enigmail has a problem with the "*" in the delimiter, but I'll need to check this.
I believe that the boundary specification is not compliant to RFC 2046. RFC 2046, section 5.1.1 specifies the MIME boundary as:
The boundaries in the example message are:
NEXT_PART*f8f6420e83e08cf2070c584f5985d91e
NEXT_PART*9OiC9lPe_iRtSlWyCZuTs53_QSYT
That is, both contain a "*" which is not a legal character for a MIME boundary.
Thank you very much for your help!
I'm sorry for stressing you with non RFC-conform e-Mail.