Beta2 of 1.3.2 wont compile
we believe we've fixed a lot of this in 1.4.0, and we have an open ticket for the char stuff. I'm closing this out here in preparation for collapsing this site.
get rid of old internal SPF code
we've targeted this for 1.5.0, which we'll add on github, resolving.
DNS issues if dmarc policy is using a CNAME
This is a duplicate of a ticket already on github, resolving.
please move to github
We are on github, and slowly pruning tickets off.
DMARC fails when spf and dkim
DNS issues if dmarc policy is using a CNAME
Options DomainWhitelist not work (ARC-Authentication-Results header)
This still remains as an issue, at least in RHEL7 (1.3.2-1.el7). Verified by tracing opendmarc and sending USR1 signal. No action was taken. HUP signal caused it to terminate. Workaround: must restart opendmarc
dmarcf_loadlist() incorrectly handles leading whitespace
Sorry, opened in mistake
DMARC fails when spf and dkim
Security Bugs: authentication results injections attacks affecting OpenDMARC that can bypass DMARC authentication
Missing link: https://www.mail-archive.com/dmarc@ietf.org/msg04816.html
DMARC aggregate report doesn't follow RFC guidelines
afaik '= NULL' should at least be 'IS NULL' with mysql/mariadb in order to work as intended
I think it is, but just to be sure: is this the same vuln reported at https://github.com/trusteddomainproject/OpenDMARC/pull/48 and https://www.golem.de/news/opendmarc-aktiv-ausgenutzte-dmarc-sicherheitsluecke-ohne-fix-1909-143798.html ?
Ping?
Why was this never merged?
Yep, you are right. Parsing of the Received-SPF header is too simple. It does not look at the identity, just at the result. So even a Received-SPF header already present in the incoming mail would be taken... This assumes, that OpenDMARC is configured to not use the internal SPF code and that no Authentication-Results header for SPF is present.
Can you retest with pypolicyd-spf set to AR mode (Header_Type = AR)?
Thanks for your questions. Here is the detailed steps to reproduce the attack: 1.Software version Postfix v3.3.0 pypolicyd-spf v2.0.2 opendmarc v1.3.2 2.Configuration Postfix enables pypolicyd-spf in its master.conf file. policy-spf unix - n n - - spawn user=nobody argv=/usr/local/bin/policyd-spf pypolicyd-spf use its default configuration. debugLevel = 5 TestOnly = 1 HELO_reject = Fail Mail_From_reject = Fail PermError_reject = False TempError_Defer = False skip_addresses = 127.0.0.0/8,::ffff:127.0.0.0/104,::1...
Why do you accept mail from a non-exisitent domain in the first place? Are you absolutely sure that OpenDMARC uses the MAIL FROM and not the FROM? Actually, OpenDMARC should never look at the MAIL FROM... Please provide some real log excerpts that show output from pypolicyd-spf, OpenDMARC and the used MTA.
Security Bug: OpenDMARC can can be bypassed when it's used with pypolicyd-spf
On Thu, 21 Mar 2019 at 13:52, Rainer Sokoll rsokoll@users.sourceforge.net wrote: Are you sure that opendmarc tests NOT against the envelope-from? Isn't SRS made exactly for rewriting the envelope-from and not the header-from? And is there anything I can do here (operator of the rejecting mail server)? For an explanation about DMARC see, for example: https://www.sparkpost.com/resources/email-explained/dmarc-explained/ You haven't provided full details and have obfuscated, but it looks like the problem...
Are you sure that opendmarc tests NOT against the envelope-from? Isn't SRS made exactly for rewriting the envelope-from and not the header-from? And is there anything I can do here (operator of the rejecting mail server)?
On Thu, 21 Mar 2019 at 13:02, Rainer Sokoll rsokoll@users.sourceforge.net wrote: Hi, this log: Mar 20 04:15:09 mx2 postfix/cleanup[10493]: 2E5F7610B4: milter-reject: END-OF-MESSAGE from o1.f.az.sendgrid.net[208.117.55.132]: 5.7.1 rejected by DMARC policy for example.com; from=bounces+4491766-4033-jdoe=example.com@sendgrid.net to=jdoe@example.com proto=ESMTP helo=<o1.f.az.sendgrid.net></o1.f.az.sendgrid.net> (original domain replaced with example.com) I do not understand much about SRS, but it seems...
Hi, this log: Mar 20 04:15:09 mx2 postfix/cleanup[10493]: 2E5F7610B4: milter-reject: END-OF-MESSAGE from o1.f.az.sendgrid.net[208.117.55.132]: 5.7.1 rejected by DMARC policy for example.com; from=<bounces+4491766-4033-jdoe=example.com@sendgrid.net> to=<jdoe@example.com> proto=ESMTP helo=<o1.f.az.sendgrid.net> (original domain replaced with example.com) I do not understand much about SRS, but it seems to me sendgrid uses SRS here to rewrite the original sender's address (jdoe@example.com). So my question...
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...
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....
Yes, I think both opendmarc and gmail are treating ""Amazon.co.uk" campaign-response@amazon.co.uk " as the name part of the from header, and checking the last address for dmarc alignment. Maybe that's part of the spec, I don't know. But I have seen people exploiting this in the wild. It's confusing to end user and admin alike, and some email clients don't make it clear who the email is really from.
My feeling is that in the OP's original example this should pass: From: "Amazon.co.uk" <campaign-response@amazon.co.uk> <info@mejorargentina.com> because the From header address is info@majorargentina.com, and the earlier part of the line is just the 'text'. I agree though that it looks confusing - intentionally on the part of the malicious sender. Blocking it, although logical, is (I suspect, have not checked) a breach of the DMARC spec.
Gmail will also give this a dmarc pass. Is this a problem with opendmarc, or with the way email clients display the from header?
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.
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...
FYI, there's a typo in the man page in the patch. It should be about avoid mutual reports, not single reports (like in the sample conf file).
hmiller skrev den 2018-12-06 10:47: I'm seeing the same bug with opendmarc-1.3.2-0.12.el7.x86_6.rpm opendmarc: SPF(mailfrom): luke@biomedservices.ie pass opendmarc: paypal.com pass Malicious From: field able to bypass DMARC [1] clearly a bug, there is no dmarc on biomedservices.ie try opendmarc build from github
I'm seeing the same bug with opendmarc-1.3.2-0.12.el7.x86_6.rpm client=outbound-smtp08.blacknight.com[46.22.139.13] helo=outbound-smtp08.blacknight.com From: service-online@paypal.com,luke@biomedservices.ie Subject: "PayPal payment received" Tests: [BAYES_00=-1.9,DKIM_ADSP_DISCARD=10,HEADER_FROM_DIFFERENT_DOMAINS=0.001,HTML_FONT_LOW_CONTRAST=0.001,HTML_MESSAGE=0.001,MIME_HTML_ONLY=0.723,SPF_PASS=-0.001,T_KAM_HTML_FONT_INVALID=0.01] opendmarc: SPF(mailfrom): luke@biomedservices.ie pass opendmarc:...
I received a spam email today claiming to be from Amazon. In the email was the following From: line From: "Amazon.co.uk" <campaign-response@amazon.co.uk> <info@mejorargentina.com> On Virgin Media's server the Authentication checks ended up being done against the latter address. Authentication-Results: ukmail.iss.as9143.net; spf=pass (200.26.191.13;mejorargentina.com); dkim=pass header.d=mejorargentina.com; dmarc=none header.from=mejorargentina.com (dis=no_record); I tried sending a dummy mail with...
I've set up opendkim/dmarc with my postfix. But it seems open dmarc uses 5321 from field instead of 5322. I've recived a message with this fields. It spoofs RFC5322.from address. From: =?utf-8?B?0JPQsNC70LjQvdCw?= info@mydomain.com Envelope-From: info@unknown.kvrwetech.local Return-Path: info@unknown.kvrwetech.local I've checked postfix logs and seen that opendmarc uses RFC5321.from field. Is it a bug, or have I done something wrong? Oct 31 13:05:41 opendkim[1714]: 3E77460021: [112.196.21.190] [112.196.21.190]...
DMARC alignment check fails when the address in the From header has a trailing whitespace
pdomain field was incorrectly retrieved
Sorry, probably I didn't explain myself properly. I mean that to send out email my server (exim) require the sender to be authenticated against the SMTP Server, so yes, I meant this: "If you mean instead, that the opendmarc-reports command needs to authenticate towards the SMTP server then this is something completely different from what I understood." :) Best regards
i understand your initial message in a mannter, that you request opendmarc to include in the Authenticaion-Results headers also information about the SMTP Auth status, like: Authenticaion-Resulsts: mysite/1234random768; auth=pass (PLAIN) smtp.auth=sandro where sandro is the username used for the authentication. And this Authentication-Result shall be both included in the emails passing opendmarc and in the reports generated by opendmarc. If you mean instead, that the opendmarc-reports command needs...
I am sorry I am confused, what this have to do with SMTP Authentication neededd to send out email? This may be useful to use an external/remote SMTP Server for example. Anyway I am using exim :=) Best regards
Could you close the ticket yourself?
Can you please close the ticket, as it is a duplicate? Then other users do not have to deal with outdated text.
Can you close this ticket? Then users checking the status do not have to read outdated text.
While today _dmarc.dealnews.com's TXT record is not quoted anymore, it is probably a better idea to generate a report stating the record is invalid. A pretty common error is not to include p=immediately after v=DMARC1;. After all, opendmarc itself and other software needs to be teached to handle quoted records.
In the sendmail's .mc files I have for this: LOCAL_CONFIG HAuthentication-Results: $j/$i; auth=pass (${auth_type}) smtp.auth=${auth_authen} I don't think this is opendmarc's job: opendkim adds its own Authentication-Results headers and it is unclear why exactly opendmarc's shall add auth=pass and not some other milter. Anyway, I think it would be feasible, if opendmarc deletes all Authentication-Results from the current MTA/host and inserts a single one, including smtp and dkim checks. This would...
Hello, A merge request has been generated: https://sourceforge.net/p/opendmarc/code/merge-requests/8/ -Jim P.
missing colon in log msg 'ignoring Authentication-Results'
Ah, please disregard. I notice #227 is exactly the same issue and includes the same patch! Thanks.
opendmarc_policy_parse_dmarc can crash on malformed DMARC records
I'm not the maintainer of OpenDMARC, but I think allowing arbitrarily long lines will open a DOS vector and I don't see a reason to do so. Why do we need arbitrarily long lines? What is wrong with a length of 1024 characters? As long as we handle it gracefully if a line is longer, I don't see a problem. We might need to raise the limit to 4096 or even 8192 to handle path length that are close to the limit of PATH_MAX, but arbitrarily long lines?
No, currently not - as far as I know. Garbage in, garbage out... It might get fixed by the above change or by my patch from ticket #206, which implements authorization checks as well.
Is that already fixed?
To fix this bug we are used attached patch.
feedback from the compiler
please move to github
checking for idn_free in -lidn... no
I have created a pull-request to merge a fix for this issue into the development branch, see https://sourceforge.net/p/opendmarc/code/merge-requests/7/ . I'll attach it here as a patch, too. It should apply cleanly against HEAD.
fix for #227: fix segfault in opendmarc_policy_parse_dmarc()
Consistent opendmarc_policy.c Segfault When Processing DMARC Data From BlackBerry
opendmarc-reports SMTP Auth
I modified this patch to override all mailing lists passing DKIM or SPF. This help me to softly implement DMARC inbound controls. I'm trying the patch and it seems to work, I will appreciate if you find some errors or improvement to this feature.
RHEL init script have wrong startup priority
Use const in public API
Able to maliciously pass DMARC check with multiple DKIM signatures
https://sourceforge.net/p/opendmarc/code/merge-requests/6/
It seems that these timeouts happen after errors like these (email report to another domain, and that domain doesn't have the appropriate DMARC report), which keep SMTP connection opened without real traffic: 2017-09-25T10:01:31.927347+02:00 mx opendmarc-send-reports.sh[22825]: opendmarc-reports: sent report for devis-malins.com to dmarc@mailinblue.com (2.0.0 Ok: queued as 3y0xP75k5qzBrMX) 2017-09-25T10:01:33.511034+02:00 mx opendmarc-send-reports.sh[22825]: opendmarc-reports: info.webprivileges.fr...
`opendmarc_policy_fecth_fo` and `opendmarc_policy_fetch_rf` not declared in dmarc.h
We have also encountered this problem. I is a problem in the library, it can be proven with a test in file libopendmarc/tests/test_alignment.c /* 11 */ {"a.example.com", "b.example.com", DMARC_RECORD_A_STRICT, -1}, /* 12 */ {"example.com", "b.example.com", DMARC_RECORD_A_STRICT, -1}, /* 13 */ {"a.example.com", "seznam.com", DMARC_RECORD_A_STRICT, -1}, which all fail
I agree. It would be great to be able to specify a file instead of specifying all domains in the config file.
I think the right solution for your problem would be to introduce a new config option hat specifies a file holding a list of domain names (MailFrom) that should be ignored.
The arbitrarily long lines allow me to add as many domains to IgnoreMailFrom. Since some domain names are pretty long, it's easy to hit the limit.
I'm not the maintainer of OpenMARC, but I think allowing arbitrarily long lines will open a DOS vector and I don't see a reason to do so. Why do we need arbitrarily long lines? What is wrong with a length of 1024 characters? As long as we handle it gracefully if a line is longer, I don't see a problem. We might need to raise the limit to 4096 or even 8192 to handle path length that are close to the limit of PATH_MAX, but arbitrarily long lines?
Allow arbitrarily long configuration file lines
Grr, formatting (edit, also had a regex typo): --- /usr/sbin/opendmarc-reports.orig 2017-09-01 10:20:31.633000000 -0700 +++ /usr/sbin/opendmarc-reports 2017-09-05 10:32:51.579000000 -0700 @@ -848,6 +848,9 @@ my $datestr; my $report_id; + # Strip trailing double quotes from incorrectly quoted DMARC TXT records + $repdest =~ s/\"$//g; + if (!open($zipin, $zipfile)) { print STDERR "$progname: can't read zipped report for $domain: $!\n"; eck for max report size
Grr, formatting (edit, also had a regex typo): --- /usr/sbin/opendmarc-reports.orig 2017-09-01 10:20:31.633000000 -0700 +++ /usr/sbin/opendmarc-reports 2017-09-01 10:35:32.647000000 -0700 @@ -798,6 +798,7 @@ } $repdest = $uri->opaque; + $repdest =~ s/\"$//g; my $report_maxbytes = $report_maxbytes_global; # check for max report size
Grr, formatting (edit, also had a regex typo): --- /usr/sbin/opendmarc-reports.orig 2017-09-01 10:20:31.633000000 -0700 +++ /usr/sbin/opendmarc-reports 2017-09-01 10:35:32.647000000 -0700 @@ -798,6 +798,7 @@ } $repdest = $uri->opaque; + $repdest =~ s/\"$//g; my $report_maxbytes = $report_maxbytes_global; # check for max report size
Grr, formatting: --- /usr/sbin/opendmarc-reports.orig 2017-09-01 10:20:31.633000000 -0700 +++ /usr/sbin/opendmarc-reports 2017-09-01 10:35:32.647000000 -0700 @@ -798,6 +798,7 @@ } $repdest = $uri->opaque; + $repdest =~ s/\"$//g; my $report_maxbytes = $report_maxbytes_global; # check for max report size
Grr, formatting: --- /usr/sbin/opendmarc-reports.orig 2017-09-01 10:20:31.633000000 -0700 +++ /usr/sbin/opendmarc-reports 2017-09-01 10:35:32.647000000 -0700 @@ -798,6 +798,7 @@ } $repdest = $uri->opaque; + $repdest =~ s/$\"//g; my $report_maxbytes = $report_maxbytes_global; # check for max report size
Tiny patch to opendmarc-reports to work around DMARC record issues
example domain: endutec.de
handle uncommon _dmarc records in a RFC 7489 comformant way
Thanks Juri.
Hello Dominic, this is not a bug but by design. The policy of the domain is recorded in the 'p' and 'sp' fields. The 'policy' field records the result of the DMARC evaluation and the 'action' field records, what was actually done. So having 'policy 15' (pass) in most cases is expected and good. And of course you will not find a single instance where 'policy 15' (pass) and 'action 0' (reject) - that would be a bug. For future question, please use the mailing list, not the ticket system.
I now realise that the field that records the domain policy is 'p', while the subdomain policy (if any) is recorded in 'sp', not 'policy'. I don't know what the 'policy' field records, maybe nothing meaningful?
HistoryFile policy field not recording correctly?
I haven't had this issue yet, but I've encontered a similar (although not as severe) endless loop with aggregate reports. I've noticed hosts sending me a report of a single message everyday. I have figured out we were sending each other aggregate reports about the delivery of each other's aggregate reports. What I have done was to create a config entry with a list of email addresses that would prevent opendmarc from recording a history file entry, and I've exteded it to not generate a failure report...
Hi Juri, Thanks for your advice. Specifing TrustedAuthservIDs "myhost.com" resolved this issue. I appreciate your help.
Difficult to say with only obfuscated logs and no configuration file, but presumably because of: opendmarc[1347]: ignoring Authentication-Results at 1 from myhost.com Most likely you have set TrustedAuthservIDs to something different than "myhost.com" or you have not set it at all and your hostname is not "myhost.com". (Btw, such questions are better suited for the user mailing list.)
[DKIM verification successful] does not result in dmarc pass
Fix for fix for bug #203.
Add ARC override.
Revert version change.