Possible issue when matching Original-Mail-From containing a domain name in the local part
endoflevelboss opened this issue · 6 comments
I'm getting auth failure reports that I can't make sense of, from two particular senders. Looking closer, there seems to be a pattern. In both cases, SPF and DKIM checks are correct. DMARC still complains about header.from, what actually is correct.
Feedback-Type: auth-failure
Version: 1
User-Agent: OpenDMARC-Filter/1.4.1
Auth-Failure: dmarc
Authentication-Results: server.com; dmarc=fail header.from=booking.com
Original-Envelope-Id: XXXXX
Original-Mail-From: bounces+123456-abcd-john.doe=server.com@sg.booking.com
Source-IP: 127.0.0.1 (localhost)
Reported-Domain: booking.com
There is another case that shows an identical pattern:
Feedback-Type: auth-failure
Version: 1
User-Agent: OpenDMARC-Filter/1.4.1
Auth-Failure: dmarc
Authentication-Results: server.com; dmarc=fail header.from=twitter.com
Original-Envelope-Id: XXXXX
Original-Mail-From: 123456789-abcdefghijklmnop-johndoe===server.com@bounce.twitter.com
Source-IP: 127.0.0.1 (localhost)
Reported-Domain: twitter.com
There's (a) a subdomain in the Original-Mail-From and (b) there is a string matching a domain name in the local part of Original-Mail-From
I'm speculating whether there could be an issue in matching the Original-Mail-From string against a domain name of the sender and the wrong part is returned and causes the check to fail.
I can provide more header information if that's helpful.
Possibly related to #206
I never had issues receiving emails from Twitter, and given the reported Source-IP it seems the server running OpenDMARC milter is different than the one Twitter's MTA talked to, and the email has been relayed. Because of this, the server running OpenDMARC tried to match a SPF record for 127.0.0.1, which doesn't exist, resulting in rejection. (Troubleshooting would be easier if rejection reports were up to spec, but spec compliance doesn't seem to be a thing here unfortunately...)
OpenDMARC should be running on the public-facing server, rather than internal relays (or, even better, have ARC up and running to forward authentication and have it validated by every relay)
Sorry for not sticking to the rules. I will do better.
Here's more from the auth failure report.
This is an authentication failure report for an email message received from IP
127.0.0.1 on Wed, 8 Jun 2022 12:32:03 +0200 (CEST).
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.example.com XXXXX
Authentication-Results: mail.example.com;
dkim=pass (2048-bit key) header.d=twitter.com header.i=@twitter.com header.b="oHd6X7P1"
X-Virus-Scanned: amavisd-new at example.com
Received: from mail.example.com ([127.0.0.1])
by localhost (mail.example.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id O3OraK4KsquO for ;
Wed, 8 Jun 2022 12:32:01 +0200 (CEST)
Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=199.59.150.72; helo=spruce-goose-ac.twitter.com; envelope-from=123456789-abcdefghijklmnop-johndoe===example.com@bounce.twitter.com; receiver=johndoe@example.com
Received: from spruce-goose-ac.twitter.com (spruce-goose-ac.twitter.com [199.59.150.72])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mail.example.com (Postfix) with ESMTPS
for ; Wed, 8 Jun 2022 12:32:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=twitter.com;
(...)
From: Twitter
To: John Doe
Subject: XXXXXXXX
(...)
As far as I can see both DKIM and SPF have passed.
Just started to read through opendmarc_util_finddomain.c
The tokenizer looks fishy to me. Will try to put together a simple test case to test with the suspicious string and check whether the correct domain is reported back.
Sorry for not sticking to the rules. I will do better.
Well it's more about the fact the report itself is incomplete, a spec-compliant report would tell precisely what went wrong (spf? dkim? and so on). Both failure and aggregate reports generated by opendmarc are out of spec 😅
As of the mail itself, it appears that both are valid, which seems quite odd. I guess the 127.0.0.1 IP comes from the amavisd content_filter, but shouldn't affect the outcomes of the authentication since the Received-SPF is present, and DKIM passes...
The tokenizer looks fishy to me.
That'd unfortunately not be the first time some code here looks/behaves in a fishy way... I'm observing no issues with Debian's package, but I know they're doing their own patches so my setup might be fine just thanks to Debian's patches (or that the package avoids new bugs by sticking to 1.4.0 and backporting some patches)
"Does not work" is a legit error report. ;-)
After some testing of the tokenizer I have to correct myself. The assumed pattern is not the cause of the auth fail. opendmarc_util_finddomain() correctly returns the domain name, including the subdomain. Sorry to the tokenizer for the wrong suspicion. I'm on CentOS 7. The code I was looking into was from this repo.
From this point I can't do much as I don't know how to put together a debug environment for a milter and step through the code with real-world input data. Just from reading through the code, I can't tell what condition triggers the auth error.
I'll take your above advice to check my setup. Maybe the auth fail is a side effect of another issue with my mail processing chain. Thank you for the pointer.
You could maybe take a look at how docker-mailserver is configured, it's been a great resource for me and uses amavisd too.
There is also this StackOverflow post which might also help you troubleshooting your problems/configuration.