Invalid incoming DKIM signature

[B4dM4n]

Hi,

I recently noticed that mails from Gmail that include inline images or attachments are marked as DKIM_INVALID by SpamAssasin.

X-SPAM-LEVEL: Spam detection results:  1
    AWL                    -2.181 Adjusted score from AWL reputation of From: address
    BAYES_05                 -0.5 Bayes spam probability is 1 to 5%
    DKIM_ADSP_CUSTOM_MED    0.001 No valid author signature, adsp_override is CUSTOM_MED
    DKIM_INVALID              0.1 DKIM or DK signature exists, but is not valid
    DKIM_SIGNED               0.1 Message has a DKIM or DK signature, not necessarily valid
    FREEMAIL_ENVFROM_END_DIGIT   0.25 Envelope-from freemail username ends in digit
    FREEMAIL_FROM           0.001 Sender email is commonly abused enduser mail provider
    HTML_IMAGE_ONLY_04      1.172 HTML: images with 0-400 bytes of words
    HTML_MESSAGE            0.001 HTML included in message
    KAM_DMARC_STATUS         0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
    KAM_NUMSUBJECT            0.5 Subject ends in numbers excluding current years
    MPART_ALT_DIFF           0.79 HTML and text parts are different
    NML_ADSP_CUSTOM_MED       0.9 ADSP custom_med hit, and not from a mailing list
    RCVD_IN_DNSWL_NONE     -0.0001 Sender listed at https://www.dnswl.org/, no trust
    RCVD_IN_MSPIKE_H2      -0.001 Average reputation (+2)
    SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
    SPF_PASS               -0.001 SPF: sender matches SPF record
    TVD_SPACE_RATIO         0.001 -

When sending the same mail from Gmail to two recipients, one behind a PMG, the content is encoded slightly different, which let's the DKIM validation fail.

Received through PMG:

...
Content-Type: multipart/related; boundary="0000000000009c7da905b6972c21"

--0000000000009c7da905b6972c21
Content-Type: multipart/alternative; boundary="0000000000009c7da805b6972c20"

--0000000000009c7da805b6972c20
Content-Type: text/plain; charset="UTF-8"

[image: image.png]

--0000000000009c7da805b6972c20
Content-Type: text/html; charset="UTF-8"

<div dir="ltr"><img src="cid:ii_kirm7xah0" alt="image.png" width="542" height="476"><br><br></div>

--0000000000009c7da805b6972c20--

--0000000000009c7da905b6972c21
Content-Type: image/png; name="image.png"
Content-Disposition: inline; filename="image.png"
Content-Transfer-Encoding: base64
Content-ID: <ii_kirm7xah0>
X-Attachment-Id: ii_kirm7xah0

RG8gMTcuIERleiAxMjozNzo0MSBDRVQgMjAyMAo=
--0000000000009c7da905b6972c21--

Received without PMG:

...
Content-Type: multipart/related; boundary="0000000000009c7da905b6972c21"

--0000000000009c7da905b6972c21
Content-Type: multipart/alternative; boundary="0000000000009c7da805b6972c20"

--0000000000009c7da805b6972c20
Content-Type: text/plain; charset="UTF-8"

[image: image.png]

--0000000000009c7da805b6972c20
Content-Type: text/html; charset="UTF-8"

<div dir="ltr"><img src="cid:ii_kirm7xah0" alt="image.png" width="542" height="476"><br><br></div>

--0000000000009c7da805b6972c20--
--0000000000009c7da905b6972c21
Content-Type: image/png; name="image.png"
Content-Disposition: inline; filename="image.png"
Content-Transfer-Encoding: base64
Content-ID: <ii_kirm7xah0>
X-Attachment-Id: ii_kirm7xah0

RG8gMTcuIERleiAxMjozNzo0MSBDRVQgMjAyMAo=
--0000000000009c7da905b6972c21--

The difference is a additional newline between the --0000000000009c7da805b6972c20-- end boundary and the next --0000000000009c7da905b6972c21 boundary.

Digging through the PMG code showed that mails are always read with MIME::Parser and later assembled again with MIME::Entity->print. The issues seems to happen because MIME::Parser can't differentiate between

--0000000000009c7da805b6972c20--

--0000000000009c7da905b6972c21

and

--0000000000009c7da805b6972c20--
--0000000000009c7da905b6972c21

Both result in the same parsed $entity.

Does anyone have an idea how to best solve the problem?

 

[Stoiko Ivanov]

What's your Maximum Spam Size setting? (GUI->Administration->Spam Detector->Options)?

* I managed to reproduce the issue here - and then remembered, that we truncate the message to the Maximum Spam Size before passing it to SpamAssassin -> setting it higher (or sending smaller mails) and the signature verifies ok

(keep in mind that there is a 33% overhead for base64 encoding when increasing it)

I hope this helps!

 

[B4dM4n]

Thanks for the Maximum Spam Size setting hint. Increasing it from 250k seems to have fixed the issue.

It would be nice if the DKIM validation gets disabled when the message is truncated.

 

[Stoiko Ivanov]

It would be nice if the DKIM validation gets disabled when the message is truncated.

DKIM validation is done by spamassassin, and spamassassin's ruleset are all loaded on program(=pmg-smtp-filter) start - so this is not really possible directly.

We might implement https://bugzilla.proxmox.com/show_bug.cgi?id=2517 at some point - which should result in having a DKIM verification for the complete mail despite truncation for spamassassin... (no promises on when/if this will happen as usual)

 

[rawtsg]

Any updates? We faced exactly the same problem.

 

[rawtsg]

The issue occurs when there is an attachment or when the size of the letter is rather large.