Yes, it is true that the spec says
If a conclusive determination about the
message can be made based on a check of "HELO", then the use of DNS
resources to process the typically more complex "MAIL FROM" *can* be
avoided.
However, it carefully avoids defining "definitive", which means the
interpretation of "definitive" is site-specific. To my interpretation,
"definitive" means a local policy to whitelist or blacklist based
exclusively on the HELO parameters. Such as decision will certainly allow
other operations to be omitted.
This interpretation is supported by the previous paragraph:
It is RECOMMENDED that SPF verifiers not only check the "MAIL FROM"
identity but also separately check the "HELO" identity by applying
the check_host() function (Section 4
<https://tools.ietf.org/html/rfc7208#section-4>) to the "HELO"
identity as the
<sender>.
and the subsequent paragraph:
SPF verifiers MUST check the "MAIL FROM" identity if a "HELO" check
either has not been performed or has not reached a definitive policy
result by applying the check_host() function to the "MAIL FROM"
identity as the <sender>.
We really have two different tests, which appear in the same document
because they exploit the same technology.
The limitations of Received-SPF become very conspicuous and problematic:
- The identifiers are only provided in comment text, which is optional
and has been omitted in the wild.
- Although comment text implementations appear to be standardized,
this is still less reliable than structured data.
- Even when the comment text can be parsed, only domain names are
provided, and the test type is not documented,
so there is no way to know whether the result is based on HELO or SMTP Address.
- Received-SPF needs to report two results for entities which perform
both tests, but multiple results simply create ambiguity..
- The Received-SPF cannot be linked to a specific Received entry.
The assumption is that it will only be used
within a single ADMD, where the perimeter is known and all internal
MTAs are trusted.
We have integrated Received-SPF into A-R without improvement, and A-R
has been integrated into ARC without significant redesign.
Then we are hoping that a third-party organization will trust an ARC
which is based on this weak foundation.
DF
>
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
