DKIM sign subdomains

1,079 views
Skip to first unread message

Alex JOST

unread,
Jun 7, 2017, 6:11:17 AM6/7/17
to rsp...@googlegroups.com
Is it actually possible to sign subdomains with the DKIM signing module?

We are currently using 'selector_map' and 'path_map'. I've tried to
include wildcards in the map files but this didn't work out as expected.

--
Alex JOST

Andrew Lewis

unread,
Jun 7, 2017, 9:04:52 AM6/7/17
to rsp...@googlegroups.com

Hi Alex,

> Is it actually possible to sign subdomains with the DKIM signing module?

Yes. use_esld = false; # means that bar.example.com won't be
normalised to example.com for any purpose- ie. selection of signing
domain; matching header vs envelope from domain & matching auth user
domain

The domain used for signing is extracted from MIME From (default) or
SMTP From according to configuration.

That may be more/less helpful depending on your environment (if you
need to support a mix of subdomains and eSLDs that might be
troublesome).

If you have complex requirements you might try DKIM module's
sign_condition (or if you want to sign all mail with the same domain
it is simplest):
https://rspamd.com/doc/modules/dkim.html#dkim-signatures and/or you
could suggest functionality in DKIM signing module which would support
your use-cases (I thought about adding ability to transform signing
domain into something else with a map lookup - maybe it would help).

Best,
-AL.

Alex JOST

unread,
Jun 7, 2017, 9:42:48 AM6/7/17
to rsp...@googlegroups.com
Hey,

>> Is it actually possible to sign subdomains with the DKIM signing module?
>
> Yes. use_esld = false; # means that bar.example.com won't be normalised
> to example.com for any purpose- ie. selection of signing domain;
> matching header vs envelope from domain & matching auth user domain
>
> The domain used for signing is extracted from MIME From (default) or
> SMTP From according to configuration.
>
> That may be more/less helpful depending on your environment (if you need
> to support a mix of subdomains and eSLDs that might be troublesome).

TBH, I don't know what eSLD stands for. Effective second-level domain?
What does that mean?


> If you have complex requirements you might try DKIM module's
> sign_condition (or if you want to sign all mail with the same domain it
> is simplest): https://rspamd.com/doc/modules/dkim.html#dkim-signatures
> and/or you could suggest functionality in DKIM signing module which
> would support your use-cases (I thought about adding ability to
> transform signing domain into something else with a map lookup - maybe
> it would help).

I simply wanted to save myself some time and use the same key/selector
for every hostname of a certain domain. That way I don't have to edit
the maps every time a server is added/removed.

/etc/rspamd/maps/dkim_paths.map:
example.com /etc/rspamd/dkim/dkim_selector1.key
*.example.com /etc/rspamd/dkim/dkim_selector2.key


/etc/rspamd/maps/dkim_selectors.map:
example.com selector1
*.example.com selector2


PS: I've just now realized that the description of the problem I'm
trying to solve was quite poorly. :(

--
Alex JOST

Andrew Lewis

unread,
Jun 7, 2017, 9:56:55 AM6/7/17
to rsp...@googlegroups.com
Hi,

> TBH, I don't know what eSLD stands for. Effective second-level domain?

Yes.

> What does that mean?

Second-level domain or something that's effectively so like
example.com or example.za.org.

> I simply wanted to save myself some time and use the same
> key/selector for every hostname of a certain domain.

Default configuration does this - but it doesn't use subdomains for
signing, it uses the eSLD.

Do you need to use default selector and path for some other purpose?
If not you could use those.

> /etc/rspamd/maps/dkim_paths.map:
> example.com /etc/rspamd/dkim/dkim_selector1.key
> *.example.com /etc/rspamd/dkim/dkim_selector2.key
> /etc/rspamd/maps/dkim_selectors.map:
> example.com selector1
> *.example.com selector2

That's a breaking change I'm afraid; these are not regex maps. Maybe
`use_esld = false` works for your purposes.

Best,
-AL.

Alex JOST

unread,
Jun 7, 2017, 10:16:47 AM6/7/17
to rsp...@googlegroups.com
Hey,

>> TBH, I don't know what eSLD stands for. Effective second-level domain?
>
> Yes.
>
>> What does that mean?
>
> Second-level domain or something that's effectively so like example.com
> or example.za.org.

Thanks for the explanation. Learning something new every day. :)


>> I simply wanted to save myself some time and use the same key/selector
>> for every hostname of a certain domain.
>
> Default configuration does this - but it doesn't use subdomains for
> signing, it uses the eSLD.
>
> Do you need to use default selector and path for some other purpose? If
> not you could use those.

This might be a feasible solution but I need to think about any future
complication with this.


>> /etc/rspamd/maps/dkim_paths.map:
>> example.com /etc/rspamd/dkim/dkim_selector1.key
>> *.example.com /etc/rspamd/dkim/dkim_selector2.key
>> /etc/rspamd/maps/dkim_selectors.map:
>> example.com selector1
>> *.example.com selector2
>
> That's a breaking change I'm afraid; these are not regex maps. Maybe
> `use_esld = false` works for your purposes.

I suppose this invalidates the signature when the message is send with
'From: <ro...@server.example.com>' but signed with 'd=example.com'.


Thinking about this further it might just be the best solution to
rewrite every From to a certain TLD address within Postfix. You never
know which 'From' a program might try to use.

--
Alex JOST

Andrew Lewis

unread,
Jun 7, 2017, 12:15:41 PM6/7/17
to rsp...@googlegroups.com

> I suppose this invalidates the signature when the message is send
> with 'From: <ro...@server.example.com>' but signed with
> 'd=example.com'.

Hummm, no, why? Domain used for DKIM signing could be completely
arbitrary/unrelated. For DMARC to pass, assuming relaxed policy
(default if unspecified), signing From: b...@foo.example.com with
d=example.com is fine.

Best,
-AL.

Alex JOST

unread,
Jun 7, 2017, 1:03:55 PM6/7/17
to rsp...@googlegroups.com
The DKIM Verfier Addon in Thunderbird shows a warning when the sender
doesn't match the signing domain. That's why I was under the impression
this is not valid. I've now read up on RFC 4871 which explicitly states
what you already wrote. Thanks for the clarification!

--
Alex JOST
Reply all
Reply to author
Forward
0 new messages