Yes, it does matter. Because one very large DMARC reporter has read this
item in the specification's XML, and actually *is* providing far more
than 2 SPF results per record object. I've counted 312 <spf> blocks in
one instance. I'm not clear on the logic behind that, perhaps it's an
aggregation level. But I don't grok it, and I want to either understand
how it makes sense, or fix the spec to be entirely clear.
On 3/15/16 16:10, Franck Martin wrote:
------------------------------------------------------------------------
*From: *"Tomki" <[email protected]>
*To: *"dmarc" <[email protected]>
*Sent: *Tuesday, March 15, 2016 3:27:15 PM
*Subject: *[dmarc-ietf] SPFAuthResultType unbounded
Does it make sense that SPFAuthResultType element counts are allowed to be
unbounded?
I would think that it should be a maximum of 2, and then only if the scope
is indicated (helo/mfrom)
fromhttps://tools.ietf.org/html/rfc7489
<xs:complexType name="AuthResultType">
<xs:sequence>
<!-- There may be no DKIM signatures, or multiple DKIM
signatures. -->
<xs:element name="dkim" type="DKIMAuthResultType"
minOccurs="0" maxOccurs="unbounded"/>
<!-- There will always be at least one SPF result. -->
<xs:element name="spf" type="SPFAuthResultType" minOccurs="1"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
Makes sense, does it matter?
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
