On Tue 02/Feb/2021 20:13:42 +0100 John R Levine wrote:
There is some commented out code to not pass a HELO result to DMARC, don't
remember why I turned it off.
Couldn't find the code you uncommented in.
Apparently, OpenDMARC reads Authentication-Results: (or Received-SPF:) and
calls opendmarc_policy_store_spf() to save the result it parsed. That way, the
last value found is the one that will be used.
It seems that relies on upstream SPF filters writing a single SPF result. If
mfrom is given write its result, otherwise write helo's. That behavior is
presumably coded after DMARC's idiosyncrasy. It would choke if applied to an
unskewed SPF filter's results.
Again, I believe this is typical of what DMARC validators do.
Yes. Here's an example by Google. You may note that the helo name reported in
Received: must have resulted in an spf=pass, which is not reported:
ARC-Authentication-Results: i=1; mx.google.com;
spf=neutral (google.com: 62.94.243.226 is neither permitted nor denied
by best guess record for domain of [email protected])
[email protected];
dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=tana.it
Return-Path: <[email protected]>
Received: from wmail.tana.it (wmail.tana.it. [62.94.243.226])
by mx.google.com with ESMTP id d18si1599313edu.101.2021.02.03.08.37.32
for <[email protected]>;
Wed, 03 Feb 2021 08:38:57 -0800 (PST)
It's existing practice and I see no reason to change it.
Software changes all the time. If we change, this particular fix would
probably be less noticeable than many other software bugs lurking amid the
code. Indeed, you have to craft a message on purpose in order to have mfrom
fail while helo pass (as the example above).
We can even explicitly allow the existing behavior for historical reasons, if
nobody recalls why the spec came out that way.
However, please, let's not write a quirky spec.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
