I'm running OpenDMARC for a couple of days now on my email server. It
mostly runs ok, but I've just got some weird failure reports.
My setup:
I run Postfix and Amavisd-new as a before queue content filter.
Policyd-SFP checks SPF on the outer SMTP and add proper authentication
header.
Amavis checks DKIM and add proper authentication header.
If the mail is acceptable, Amavis handles it to the inner SMTP.
OpenDMARC can't run on outer smtp in a BQCF setup, so it runs on the
inner SMTP. Then it sees emails coming from 127.0.0.1, no big deal
because it's setup to trust Policyd-SFP header.
Unfortunately it looks like it does not trust Amavis' DKIM header. But
I'm not sure about that.
So, my setup imposes that OpenDMARC sees only 127.0.0.1 as Source-IP.
How can I be sure that it won't play against me? I can't understand the
source code of OpenDMARC, so I can't be sure the verification process
won't use that IP address, for example for SPF, even though
SPFIgnoreResults is set to false.
Thanks,
Patrick
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't see that it should be a problem if you leave the two SPF settings (SPFIgnoreResults and SPFSelfValidate) at their default 'false' settings. Why do you think it would be?
OpenDMARC will mark an SPF fail if it doesn't see an SPF approval header that it trusts.
In practice almost all senders using DMARC with p=reject or p=quarantine ensure that their emails are signed with DKIM - so they pass DMARC even with SPF fail.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, thanks for your reply. I'm not so sure about anything in fact, I'm just super cautious. May be blindly trusting everything from 127.0.0.1 makes it possible for an attacker to forge a Received-Spf header before sending the email to my MX server. It's probably policyd-spf's job to clean-up and sanitise Received-Spf headers.
For now it's no big deal because I'm not taking any action other than adding DMARC headers. But later I'll probably add some email filters to enforce quarantine and reject policies. Then it'll be very important that everything behaves as expected :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe (though not sure how, since I can't now find it documented)
that opendmarc will trust only the first (i.e. most recent) SPF
header that it finds for each matching 'TrustedAuthservIDs' string. So
if your policyd-spf daemon adds such a header to all emails (as it
should) then you can be confident that it will be this header, and not
any fake header (added previously), that will be trusted and used by
opendmarc.
Off topic: As far as I am concerned SPF is a broken technology anyway
and I wish people would stop using it. DKIM is the way to go. Some
senders using opendmarc p=reject rely on SPF to get over failings
(incorrect or missing DKIM) in their mail setups (including some big
ones such as UK HMRC). The result is occasional, hard-to-diagnose,
mail delivery failures (i.e. when the mail is subsequently relayed).
BTW you might get better response to queries by posting to the
opendmarc mailing list...
Hi, thanks for your reply. I'm not so sure about anything in fact, I'm just super cautious. May be blindly trusting everything from 127.0.0.1 makes it possible for an attacker to forge a Received-Spf header before sending the email to my MX server. It's probably policyd-spf's job to clean-up and sanitise Received-Spf headers.
For now it's no big deal because I'm not taking any action other than adding DMARC headers. But later I'll probably add some email filters to enforce quarantine and reject policies. Then it'll be very important that everything behaves as expected :)
Hello,
I'm running OpenDMARC for a couple of days now on my email server. It
mostly runs ok, but I've just got some weird failure reports.
My setup:
I run Postfix and Amavisd-new as a before queue content filter.
Policyd-SFP checks SPF on the outer SMTP and add proper authentication
header.
Amavis checks DKIM and add proper authentication header.
If the mail is acceptable, Amavis handles it to the inner SMTP.
OpenDMARC can't run on outer smtp in a BQCF setup, so it runs on the
inner SMTP. Then it sees emails coming from 127.0.0.1, no big deal
because it's setup to trust Policyd-SFP header.
Unfortunately it looks like it does not trust Amavis' DKIM header. But
I'm not sure about that.
So, my setup imposes that OpenDMARC sees only 127.0.0.1 as Source-IP.
How can I be sure that it won't play against me? I can't understand the
source code of OpenDMARC, so I can't be sure the verification process
won't use that IP address, for example for SPF, even though
SPFIgnoreResults is set to false.
Thanks,
Patrick
I don't see that it should be a problem if you leave the two SPF settings (SPFIgnoreResults and SPFSelfValidate) at their default 'false' settings. Why do you think it would be?
OpenDMARC will mark an SPF fail if it doesn't see an SPF approval header that it trusts.
In practice almost all senders using DMARC with p=reject or p=quarantine ensure that their emails are signed with DKIM - so they pass DMARC even with SPF fail.
Hi, thanks for your reply. I'm not so sure about anything in fact, I'm just super cautious. May be blindly trusting everything from 127.0.0.1 makes it possible for an attacker to forge a Received-Spf header before sending the email to my MX server. It's probably policyd-spf's job to clean-up and sanitise Received-Spf headers.
For now it's no big deal because I'm not taking any action other than adding DMARC headers. But later I'll probably add some email filters to enforce quarantine and reject policies. Then it'll be very important that everything behaves as expected :)
I believe (though not sure how, since I can't now find it documented)
that opendmarc will trust only the first (i.e. most recent) SPF
header that it finds for each matching 'TrustedAuthservIDs' string. So
if your policyd-spf daemon adds such a header to all emails (as it
should) then you can be confident that it will be this header, and not
any fake header (added previously), that will be trusted and used by
opendmarc.
Off topic: As far as I am concerned SPF is a broken technology anyway
and I wish people would stop using it. DKIM is the way to go. Some
senders using opendmarc p=reject rely on SPF to get over failings
(incorrect or missing DKIM) in their mail setups (including some big
ones such as UK HMRC). The result is occasional, hard-to-diagnose,
mail delivery failures (i.e. when the mail is subsequently relayed).
BTW you might get better response to queries by posting to the
opendmarc mailing list...
On Wed, 13 Mar 2019 at 07:59, patpro patpro@users.sourceforge.net wrote: