#91 verification does not honour t=s in public key

[Mark Martinec]

A DKIM signature in which 'i' is a subdomain of 'd'
should fail when public key demands t=s.

Seems like dkim-filter 2.3.2 and 2.4.0beta ignore
this flag in a public key, an otherwise valid signature
is not invalidated when 'i' is a subdomain of 'd'
and t in a key includes an s flag.

rfc4871
t= ...The defined flags are as follows:
s Any DKIM-Signature header fields using the "i="
tag MUST have the same domain value on the
right-hand side of the "@" in the "i=" tag and
the value of the "d=" tag. That is, the "i="
domain MUST NOT be a subdomain of "d=".

[Anonymous]

Proposed patch #1

[Anonymous]

Logged In: YES
user_id=1048957
Originator: NO

Try the attached patch.
File Added: PATCH

[Mark Martinec]

Logged In: YES
user_id=1572112
Originator: YES

> Try the attached patch.

Well, it would do as a quick-fix solution, but:

- rfc4871: Tags MUST be interpreted in a case-sensitive manner.
The dkim_param_get() uses strcasecmp !?

- flags in a 't' tag in a key are a colon-separated list
of hyphenated-words. The strchr(p,'s') would match any
letter s in any word.

[Anonymous]

Logged In: YES
user_id=1048957
Originator: NO

This appears to be part of the evolution of DKIM that I missed. Originally it was a concatenated set of characters, so "t=ys" would be both of the current flags enabled, and thus that fix would've been appropriate.

The patch to fix all of the things you've enumerated here is a little more comprehensive than I can post easily as a diff, so I'll just say Beta11 will contain all of these fixes. I'll post it later today. If you're not already watching the Beta package for updates, you might want to add yourself.

[Anonymous]

Logged In: YES
user_id=1048957
Originator: NO

v2.4.0 released, containing fixes for all of these issues.