Hi,

I have a quick question about DKIM validation in your mailing list software. The message at https://lists.sr.ht/~sirodoht/mataroa-community/%3Co7uwxdbkfoyrelu5qgudcaetsg54kjeiywdecsqnwk5e6zkqjf%402kw32aoe7zt4%3E is said to have an invalid DKIM signature, but when I take the raw message and paste it into https://www.appmaildev.com/en/dkimfile it validates fine. Unfortunately the Authentication-Results header does not tell why it failed.

Does somebody here have the possibility to get more details from the logs? I'm wondering if there was a glitch (possibly DNS lookup related?) or that there actually is something wrong with how we do dkim signatures on our outgoing messages. (I guess there'll be a verdict on the latter as soon as this message hits the archives).


Best regards,
Charlie
StartMail Engineering

> I have a quick question about DKIM validation in your mailing list software. The message at
> https://lists.sr.ht/~sirodoht/mataroa-community/%3Co7uwxdbkfoyrelu5qgudcaetsg54kjeiywdecsqnwk5e6zkqjf%402kw32aoe7zt4%3E
> is said to have an invalid DKIM signature

I'm not 100% sure of how it works, but Wikipedia says the verification
is done by searching this TXT DNS record

dkim._domainkey.startmail.com

Which I don't seem to find in your config. Could this be the reason?

I used to this other tool to verify my DKIM:
https://mxtoolbox.com/dkim.aspx

source: https://en.wikipedia.org/wiki/DKIM#Verification

hth

We use the go-msgauth library internally:

https://github.com/emersion/go-msgauth

It comes with a validation command, dkim-verify, which gives the
following:

$ curl -s https://lists.sr.ht/~sirodoht/mataroa-community/%3Co7uwxdbkfoyrelu5qgudcaetsg54kjeiywdecsqnwk5e6zkqjf%402kw32aoe7zt4%3E/raw | dkim-verify 
2023/11/20 10:06:32 Invalid signature for startmail.com: dkim: signature did not verify: crypto/rsa: verification error

On Mon Nov 20, 2023 at 10:06 AM CET, Drew DeVault wrote:
> We use the go-msgauth library internally:
>
> https://github.com/emersion/go-msgauth
>
> It comes with a validation command, dkim-verify, which gives the
> following:
>
> $ curl -s https://lists.sr.ht/~sirodoht/mataroa-community/%3Co7uwxdbkfoyrelu5qgudcaetsg54kjeiywdecsqnwk5e6zkqjf%402kw32aoe7zt4%3E/raw | dkim-verify 
> 2023/11/20 10:06:32 Invalid signature for startmail.com: dkim: signature did not verify: crypto/rsa: verification error

This seems like a bug then… MXToolbox validates it just fine

-- 
Moritz Poldrack
https://moritz.sh

Hi,

It seems like a go-msgauth bug indeed: the e-mail validates fine with
opendkim. I've opened [1] to track this. I will investigate.

Note that it seems "Sender" is included in the DKIM signature even if
it wasn't in the original message. This forbids mailing lists from
adding a proper "Sender" header field. I would recommend against signing
"Sender" if it's missing. RFC 6376 section 5.4 [2] says:

> For this reason, signing fields **present in the message** such as Date,
> Subject, Reply-To, Sender, and all MIME header fields are highly
> advised.

Emphasis mine. See also appendix B.2.3 [3] which explicitly mentions
this behavior.

Simon

[1]: https://github.com/emersion/go-msgauth/issues/58
[2]: https://datatracker.ietf.org/doc/html/rfc6376#section-5.4
[3]: https://datatracker.ietf.org/doc/html/rfc6376#appendix-B.2.3

On Monday, November 20th, 2023 at 11:42, Simon Ser <contact@emersion.fr> wrote:

> It seems like a go-msgauth bug indeed: the e-mail validates fine with
> opendkim. I've opened [1] to track this. I will investigate.

Should be fixed in go-msgauth v0.6.7.

> On 20 Nov 2023, at 13:10, Simon Ser <contact@emersion.fr> wrote:
> 
> On Monday, November 20th, 2023 at 11:42, Simon Ser <contact@emersion.fr> wrote:
> 
>> It seems like a go-msgauth bug indeed: the e-mail validates fine with
>> opendkim. I've opened [1] to track this. I will investigate.
> 
> Should be fixed in go-msgauth v0.6.7.

After looking at that bug report I've now noticed something else in the failed message: there is weird (but not wrong[0]) casing in our dkim header list, with the first message-id header instance being Message-ID (matching the message's actual header as produced by mutt) and then the oversigning one is Message-Id (which is the casing we have in our opendkim config).

My own messages do have Message-Id in the header, and the dkim header list has that casing for both regular and oversigning, and then go-msgauth does like the message.

Anyway, thanks for finding and fixing this in go-msgauth!

Best regards,
Charlie

[0] I think - I haven't studied the dkim rfcs extensively, and this is the first time we've been made aware of this

On Monday, November 20th, 2023 at 13:39, charlie@startmail.com <charlie@startmail.com> wrote:

> > On 20 Nov 2023, at 13:10, Simon Ser contact@emersion.fr wrote:
> > 
> > On Monday, November 20th, 2023 at 11:42, Simon Ser contact@emersion.fr wrote:
> > 
> > > It seems like a go-msgauth bug indeed: the e-mail validates fine with
> > > opendkim. I've opened [1] to track this. I will investigate.
> > 
> > Should be fixed in go-msgauth v0.6.7.
> 
> After looking at that bug report I've now noticed something else in
> the failed message: there is weird (but not wrong[0]) casing in our
> dkim header list, with the first message-id header instance being
> Message-ID (matching the message's actual header as produced by mutt)
> and then the oversigning one is Message-Id (which is the casing we
> have in our opendkim config).
> 
> My own messages do have Message-Id in the header, and the dkim header
> list has that casing for both regular and oversigning, and then
> go-msgauth does like the message.

Yup, that is indeed the source of the bug, and was confusing go-msgauth.
I can confirm that this isn't wrong from an RFC compliance point of view.

> Anyway, thanks for finding and fixing this in go-msgauth!

No problem!

FWIW, the fixed version of go-msgauth has been deployed on sr.ht

Cheers,
Conrad