Am 2024-08-28 um 11:34 schrieb Alessandro Vesely:
On Wed 28/Aug/2024 02:54:55 +0200 Brotman, Alex wrote:
I believe this also means I need to alter:
There MAY be an optional "envelope_from" element, which contains the
RFC5321.MailFrom domain or the RFC5321.Helo domain that the SPF check
has been applied to. This element MAY be existing but empty if the
message had a null reverse-path ([RFC5321<https://www.ietf.org/
archive/id/draft-ietf-dmarc-aggregate-reporting-17.html#RFC5321>],
Section 4.5.5).
The main document says that only the 5321.From will be used in SPF
evaluations as it relates to DMARC.
Sounds right, remove RFC5321.Helo. It's also mentioned in Appendix A:
<!-- The RFC5321.MailFrom domain or, if that value is empty,
the RFC5321.Helo domain. -->
I believe to match the “may use SPF” portion, I need to change:
The "dkim" sub-element is optional as not all messages are signed,
while there MUST be at least one "spf" sub-element.
To be: The "dkim" sub-element is optional as not all messages are
signed, while there MAY be at least one "spf" sub-element.
Text suggestion:
There MAY be a number of optional "dkim" sub-elements, one for each
checked DKIM signature. There MAY be an optional "spf" sub-element.
I'd also suggest to describe "scope" in that section:
The "spf" element MAY include an optional "scope" field with value
"mfrom" (default) or "helo" (if the message had a null reverse-path, see
Section 2.4 of [RFC7208]).
And also alter the XSL:
<xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
maxOccurs="unbounded"/>
To be: <xs:element name="spf" type="SPFAuthResultType" minOccurs="0"
maxOccurs="unbounded"/>
Does that sound reasonable?
In part only. I'd set maxOccurs="1" and change the comment like so:
OLD
<!-- There will always be at least one SPF result. -->
NEW
<!-- There will always be at most one SPF result. -->
Makes sense to me.
Regards,
Matt
_______________________________________________
dmarc mailing list -- dmarc@ietf.org
To unsubscribe send an email to dmarc-le...@ietf.org
