OpenDMARC
OpenDMARC copied to clipboard
trusteddomainproject
Add RequiredFrom option to opendmarc.conf
If RequiredFrom is set, opendmarc will reject messages that lack a From header from which a valid domain can be extracted. This is a subset of the full RFC5322 requirements enforced by the RequiredHeaders option.
While non RFC5322-compliant messages are too common to make RequiredHeaders always usable, the check on the From header remains especially valuable. It makes sure forged domain messages cannot evade the filter by just omitting the From header and relying on the MTA to fill it by a copy from the enveloppe header.
????? ???????? @.***> wrote:
Why do not you use the RequiredHeaders option for this?
I just got burned by RequiredHeaders which rejects a lot of valid e-mails that violate RFC5322 (double headers are the most common offence). Obviously it does not fit for me.
But as noted in the commit message, testing the From header is especially important, otherwise messages can slip through opendmarc by just omitting it. The MTA will copy the enveloppe sender into a new From header, and no check will be done wether it is legit or not.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz @.***
Please extend the documentation for a discussion, what kind of advantages offer the new option over RequiredHeaders . Who will want to accept an email with many Message-Id headers, but with correct From?
????? ???????? @.***> wrote:
Please extend the documentation for a discussion, what kind of advantages offer the new option over RequiredHeaders . Who will want to accept an email with many Message-Id headers, but with correct From?
You take it the wrong way around :-)
I can live with a buggy message with multiple Message-Id, but today, a message with a missing From header will go through opendmarc unblocked, the MTA will copy the envelope From into a new header From, and the user will see a forged sender domain even if it is supposed to be protected by DMARC.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz @.***
See https://github.com/trusteddomainproject/OpenDMARC/issues/202 which applies to this PR as well.
