Re: [dmarc-ietf] Ticket #1 - SPF alignment

[Douglas Foster <[e-mail]>]

I believe that most code is validating the MailFrom parameter if it is
supplied, and validating the HELO name only if MAILFROM is null.   This is
based mostly on the way SPF has been discussed over the last 15 years,
coupled with the observed behavior of a limited number of
product implementations..

If we are to argue that HELO and MAILFROM tests are interchangeable, we
have to deal with the situation where the domains are different and the
results are different.    SPF has 7 possible results, so there are 49
possible combinations of these two tests, 42 of which are divergent.   (If
we factor in NXDOMAIN as a separate result, which even RFC 7208 says is
probably appropriate for HELO, the number of divergent results is even
greater.)

To merge the tests, we would need to define a winning result for all of the
divergent result pairs, and then demonstrate that our winning result can be
considered appropriate for all installations.   Such an undertaking has not
been attempted, and I cannot imagine it achieving consensus.

The result needed for DMARC is the result I believe is actually being
produced by most installations:   The result is evaluated based on MAILFROM
when it is not null, and evaluated using HELO domain when MAILFROM is
null.   Of course, using HELO as a proxy for MAILFROM only works for bounce
messages being returned from installations hosting a single mail domain on
a matching host domain.   For everyone else, DMARC will only verify
automatic messages that are signed with the From address domain.  The DMARC
specification should make this clear to the reader.

- - -

To correct an earlier comment of mine:

fcDNS on HELO and SPF HELO tests can be used together quite effectively.
 fcDNS validates that the server is reporting a valid host name, limits the
allowed results to a single DNS domain, and demonstrates that the domain
being used for SPF HELO is the correct one.  However, fcDNS does not
demonstrate that the server is authorized to send mail.   SPF defines the
servers which are allowed to send mail for the domain, but may include IP
addresses from other domains, either directly or through Include clauses.
 When the host name is verified with both fcDNS and SPF HELO, the evaluator
knows that the server is in the reported domain and authorized by that
domain to send mail.

Note that this is also different from fcDNS on the Reverse DNS name, as
reported with the "iprev" test result.  We really do not have a way to
report test results for the HELO name.  It would seem desireable to add
test result indicators for both fcDNS HELO and fcDNS SPF.

Doug Foster



.

On Tue, Feb 2, 2021 at 2:54 PM John R Levine <[e-mail]> wrote:

> >> There is some commented out code to not pass a HELO result to DMARC,
> don't
> >> remember why I turned it off.
> >
> > I’m lost in a double negative here: did you turn off passing a HELO
> result to
> > DMARC, or did you turn off not passing a HELO result?
>
> The live code uses whichever result it has.  The commented out code only
> used a MAIL FROM result.
>
> >> Again, I believe this is typical of what DMARC validators do.  It's
> >> existing practice and I see no reason to change it.  Can we stop now?
> >
> > If you found that you needed to turn off something that’s part of the
> DMARC
> > spec, it would be good to understand why.
>
> I believe that what I am doing matches the spec.
>
> Regards,
> John Levine, [e-mail], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
> _______________________________________________
> dmarc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dmarc
>