trusteddomainproject / OpenDMARC

This is the Trusted Domain Project's impementation of the DMARC protocol libary and mail filter, called OpenDMARC. A "milter" connects to unix-based mailers (originally, sendmail, but now many) and provides a standard filtering API.
Other
101 stars 53 forks source link

OpenDMARC fails to test subdomain against parent DMARC record. #54

Open UffeRB opened 4 years ago

UffeRB commented 4 years ago

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 'TastSelv@tastselvperson.sktst.dk' in 'mfrom' identity (mechanism 'ip4:147.29.150.227' matched)) receiver=mail.example.net; identity=mailfrom; envelope-from="TastSelv@tastselvperson.sktst.dk"; 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 header.i=@tastselvperson.sktst.dk 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:547035b651@rep.dmarcanalyzer.com; ruf=mailto:547035b651@rep.dmarcanalyzer.com" $ 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

stevedwray commented 4 years ago

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

martinbogo commented 4 years ago

I just tested this against Debian 10 Postfix and can confirm the bug. I've added it to the issues to triage.

stevedwray commented 4 years ago

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!

martinbogo commented 4 years ago

On it. It's high on the priority list for triage.

On Tue, May 26, 2020 at 6:36 PM Stephen Wray notifications@github.com 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 .

UffeRB commented 4 years ago

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:urb@twe.net http://blog.andersen.nu/

martinbogo commented 4 years ago

@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.

section1 commented 5 months ago

Hi, is this still planed to be fixed ? i think its a important issue to solve.

bes-internal commented 5 months ago

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.

bes-internal commented 5 months ago

https://bugs.exim.org/show_bug.cgi?id=3090