Signing emails, was Re: General-Purpose Server for Debian Stable
On Fri 02 Oct 2020 at 01:15:36 (+0200), Linux-Fan wrote:
> Dan Ritter writes:
> > Linux-Fan wrote:
>
> [...]
>
> OT: Message signature is still invalid, but I could track it down to some
> weird changes in space characters between what I send to and what I receive
> from the list. I have now idea how to solve it, though...
Looking back at this signed post,
https://lists.debian.org/debian-user/2020/08/msg00741.html
I see the following lines:
On Sat 22 Aug 2020 at 00:17:19 (+0200), Linux-Fan wrote:
> Teemu Likonen writes:
> > * 2020-08-21 20:24:29+02, Linux-Fan wrote:
>
> [...]
>
> The copy I receive from the list does not verify correctly here, either.
> It seems somewhere along the path the e-mails content is actually mangled.
> -- some additional newlines are introduced compared to my local copy from
> the "Sent" folder which verifies correctly.
>
> Attached are `sent.txt` (and `sent.eml`) and `received.txt` -- the very same
> e-mail as seen in my Sent folder and Inbox respectively... Interestingly, if
> I split out the signatures and message contents, I get bad signature for
> both variatns despite the fact that the e-mail client can somehow verify the
> sent e-mail...
>
> ???
> Linux-Fan
> --=_pte5-5038-1598034269-0003
> Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
> Content-Disposition: inline
> Content-Transfer-Encoding: 7bit
This is the header for the "sent" file. You appear to be sending
8bit data without encoding it. AIUI that contravenes "all data signed
according to this protocol MUST be constrained to 7 bits (8-bit data
MUST be encoded using either Quoted-Printable or Base64)".
It's possible that your mailer set Content-Transfer-Encoding: 7bit
because this message happened not to contain any 8bit characters.
In my mutt, a message like that would be sent with:
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
whereas one containing 8bit chars would be sent with:
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
(Of course, I'm allowed to send 8bit because I'm not signing it.)
Whatever—somewhere in the chain of transmission, the email
gets encoded into Q-P:
> --=_pte5-5038-1598034269-0003
> Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
Unfortunately, the Content-Transfer-Encoding is AIUI part of the
signed message, so the "received" file can never match the "sent".
For whatever reason, by the time your email reaches my mailbox, the
"sent" unencoded attachment has been encoded as Q-P, and the
"received" Q-P attachment doesn't need it. As a result, the texts
of the two attachments look very similar, with their complementary
headers. Summarising, as displayed by mutt:
[-- Attachment #2: sent.txt --]
[-- Type: text/plain, Encoding: quoted-printable, Size: 1.8K --]
Content-Disposition: attachment;
FILENAME="sent.txt"
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
--=_pte5-5038-1598034269-0003
→ Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
→ Content-Disposition: inline
→ Content-Transfer-Encoding: 7bit
↑↑↑↑
and:
[-- Attachment #3: received.txt --]
[-- Type: text/plain, Encoding: 7bit, Size: 1.8K --]
Content-Disposition: attachment;
FILENAME="received.txt"
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
--=_pte5-5038-1598034269-0003
→ Content-Type: text/plain; format=flowed; delsp=yes; charset="UTF-8"
→ Content-Disposition: inline
→ Content-Transfer-Encoding: quoted-printable
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
These → lines are signed.
This is just my interpretation of RFCs 3156 and 3676. A lot of these
RFCs is about Flowed and Delsp. I've assumed that that's all being
implemented correctly. (Mixing Q-P and Flowed is tricky at best,
disallowed at worst.) BTW, I know nothing about .eml files. I'm just
happy not to see tnef files anymore.
Cheers,
David.
Reply to: