TL;DR I suspect Jolla Email re-parses the DKIM-Signature
headers wrongly back together and inserts an extra newline which is not supposed to go there.
I forwarded the same spam mail to SpamCop from my Jolla* (SFOS 3.4) and X10III (SFOS 4.5) and they are identical. Then I forwarded the spam from Thunderbird, and the file is indeed different!
Difference 1: different folding of headers (I don’t think this is it, as RFCs say folding/unfolding is rather flexible, and parser shouldn’t distinguish these)
Thunderbird:
X-Rspam-Report: Action: add header
Symbol: HAS_REPLYTO(0.00)
Symbol: R_SPF_ALLOW(0.00)
Symbol: REPLYTO_DN_EQ_FROM_DN(0.00)
Symbol: TO_DN_NONE(0.00)
Symbol: NEURAL_SPAM(0.00)
Symbol: URI_COUNT_ODD(1.00)
[...]
Jolla Email:
X-Rspam-Report: Action: add header Symbol: HAS_REPLYTO(0.00) Symbol:
R_SPF_ALLOW(0.00) Symbol: REPLYTO_DN_EQ_FROM_DN(0.00) Symbol:
TO_DN_NONE(0.00) Symbol: NEURAL_SPAM(0.00) Symbol: URI_COUNT_ODD(1.00)
[...]
Difference 2: Different location (and content) of MIME-Version
header (I don’t think this is it either):
Thunderbird: MIME-Version: 1.0
“in the middle” of headers
Jolla: Right before the first segment separator:
MIME-Version: 1.0
This is a multipart message in Mime 1.0 format
Difference 3: Extra newline in DKIM-signature
(bingo!)
Thunderbird:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=mail; d=yyy.tld;
h=Message-ID:Reply-To:From:To:Subject:Date:MIME-Version:Content-Type;
i=aaa@yyy.tld;
bh=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=;
b=bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
bbbbbbbbbbbbbbbbbbb=
Message-ID: <xxx@yyy.tld>
Jolla Email:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; s=mail;
d=yyy.tld;
h=Message-ID:Reply-To:From:To:Subject:Date:MIME-Version:Content-Type;
i=aaa@yyy.tld; bh=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=;
b=bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb bbbbbbbbbbbbbbbbbbb=
Message-ID: <xxx@yyy.tld>
Also, the folding is different for the b=
parameter, I can’t tell if it’s incorrect or not (my guess is…yes?)
So I was wrong in two ways:
- the headers are not stripped
- this was not a regression
That also explains how it may have worked before; if the DKIM header is the cause here, and it wasn’t present, then the email would be parsed correctly. That’s my best educated guess, at least.
I would edit the opening post, but I can’t do that any more. I’ll change the title though.
Could someone change the opening post to a wiki so I could update it?
*) It turns out that SFOS 3.4 can’t connect to my email service provider without enabling self-signed certs, but that’s expected since the OS has received no certificate nor OpenSSL updates in a long while.