OpenDMARC
OpenDMARC copied to clipboard
trusteddomainproject
OpenDMARC fails to test subdomain against parent DMARC record.
Hi I have received a mail from a subdomain of a DMARC enabled domain, but the authentication result is dmarc=none.
Received-SPF: pass (tastselvperson.sktst.dk: 147.29.150.227 is authorized to use '[email protected]' in 'mfrom' identity (mechanism 'ip4:147.29.150.227' matched)) receiver=mail.example.net; identity=mailfrom; envelope-from="[email protected]"; helo=bounce.skat.dk; client-ip=147.29.150.227
Authentication-Results: mail.example.net; dmarc=none (p=none dis=none) header.from=tastselvperson.sktst.dk
Authentication-Results: mail.example.net; dkim=pass (1024-bit key; unprotected) header.d=tastselvperson.sktst.dk [email protected] header.b=dr1XMWmz
The parent domain, sktst.dk have a p=reject and no sp defined:
~$ dig txt _dmarc.sktst.dk +short
"v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]"
$ dig txt _dmarc.tastselvperson.sktst.dk +short
I have successfully reproduced the behaviour from another domain. The receiving server is running Postfix with OpenDMARC 1.3.2 on FreeBSD.
It seems to me, as OpenDMARC fails to use the inherited DMARC policy from its parent domain.
Regards /Uffe
I'm seeing this as well. Debian 10, Postfix, opendmarc: OpenDMARC Filter v1.3.2 SMFI_VERSION 0x1000001 libmilter version 1.0.1 Active code options: WITH_SPF WITH_SPF2
I just tested this against Debian 10 Postfix and can confirm the bug. I've added it to the issues to triage.
Right now there aren't a lot of other options for DMARC in Linux (in fact I'm not aware of any; exim's experimental built-in DMARC support uses libopendmarc), so getting this fixed would be fantastic!
On it. It's high on the priority list for triage.
On Tue, May 26, 2020 at 6:36 PM Stephen Wray [email protected] wrote:
Right now there aren't a lot of other options for DMARC in Linux (in fact I'm not aware of any; exim's experimental built-in DMARC support uses libopendmarc), so getting this fixed would be fantastic!
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/trusteddomainproject/OpenDMARC/issues/54#issuecomment-634335584, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB5KKJANCGUBPB2ET4YUCLRTRG6ZANCNFSM4JRHFUYQ .
On 27-05-2020 04:08, Martin Bogomolni wrote:
On it. It's high on the priority list for triage.
That's great news. I am very happy to have my findings confirmed and reproduced by other users :-)
-- Med venlig hilsen - Sincerely Uffe R. B. Andersen - mailto:[email protected] http://blog.andersen.nu/
@mskucherawy is working on this. The solution is non-trivial and requires a slab of new code to be integrated and tested. This may not make it in time for a 1.5.0 issues rollup release but perhaps 1.5.1 with plenty of Beta testing time.
When this issue is merged into the 'develop' branch, I highly recommend that everyone give it a shakedown test if possible.
Hi, is this still planed to be fixed ? i think its a important issue to solve.
Raising awareness, please help.
If not taking into account other installations, according to a recent survey (2021), an estimated 60% of internet servers run on Exim. Exim uses opendmarc for native processing of spf-dkim-dmarc-arc chain.
Retrieving policy for Organizational Domain is still not working and always return p=none.
Some action is needed here.
