Amended language for section 2.1: "The report may include... - Sending domain and receiving server organizational domain."
Which organizational domain? Taking my corporate domain as an example, you send the message to “comcast.com”, which is hosted at pphosted.com (MX/Proofpoint), but ultimately resides in outlook.com (O365/M365). Should it be the domain that is the addressee, the domain that performs the DMARC (or other) evaluation? Or even the one that does the reporting? There is also the envelope_to as part of the IdentifierType data, which seems to contradict the first part of your message. Perhaps I misunderstand the objection. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: dmarc <[email protected]> On Behalf Of Douglas Foster Sent: Sunday, November 13, 2022 3:22 PM To: IETF DMARC WG <[email protected]> Subject: [dmarc-ietf] Notes on Aggregate Report draft 6 Section 2.1 --------------- This section says in part: "The report may include... - Sending and receiving domains" This language is incorrect or misleading because the receiving SMTP domain is not part of our standard reporting at all, which is intentional. (However, Yahoo has chosen to use the filename portion of the report name to indicate the receiving SMTP domain. This behavior is probably worth mentioning in a later section, since established implementations trump the prior specification.) Instead, the report design is intended to indicate the receiving MX server's organizational domain. Unfortunately, the current design and practice does not communicate this information with any confidence. We should address this by adding a field to indicate the MX server's organizational domain (or a subdomain which encompassess all of the MX servers included in the report). If MX servers are in different organizational domains, they should use separate reports. Amended language for section 2.1: "The report may include... - Sending domain and receiving server organizational domain." Additional language will be needed elsewhere to clarify these points. Section 6.1 --------------- This section says "Aggregate report may expose sender and recipient identifiers, specifically the RFC5322.From addresses." This seems contradicted by section 6.3, so I think it can be dropped. XML Definition -------------------- Consistent with the above comments, and my previous recommendation to include HELO and Reverse DNS names, the following changes are recommended to the XML Report Metadata Type ----------------------------------------- Current <xs:complexType name="ReportMetadataType"> <xs:sequence> <xs:element name="org_name" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="email" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="extra_contact_info" type="xs:string" minOccurs="0" maxOccurs="1"/> <xs:element name="report_id" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="date_range" type="DateRangeType" minOccurs="1" maxOccurs="1"/> <xs:element name="error" type="xs:string" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> Recommended <xs:complexType name="ReportMetadataType"> <xs:sequence> <xs:element name="org_name" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="email" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="extra_contact_info" type="xs:string" minOccurs="0" maxOccurs="1"/> <xs:element name="report_id" type="xs:string" minOccurs="1" maxOccurs="1"/> <xs:element name="date_range" type="DateRangeType" minOccurs="1" maxOccurs="1"/> <xs:element name="error" type="xs:string" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="MXserver_domain" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:sequence> </xs:complexType> Row Type ------------- Current <xs:complexType name="RowType"> <xs:all> <!-- The connecting IP. --> <xs:element name="source_ip" type="IPAddress" minOccurs="1" maxOccurs="1"/> <!-- The number of messages for which the PolicyEvaluatedType was applied. --> <xs:element name="count" type="xs:integer" minOccurs="1" maxOccurs="1"/> <!-- The DMARC disposition applied to matching messages. --> <xs:element name="policy_evaluated" type="PolicyEvaluatedType" minOccurs="1" maxOccurs="1"/> <xs:element name="extensions" type="ExtensionType" minOccurs="0" maxOccurs"unbounded"/> </xs:all> </xs:complexType> Recommended <xs:complexType name="RowType"> <xs:all> <!-- The connecting IP. --> <xs:element name="source_ip" type="IPAddress" minOccurs="1" maxOccurs="1"/> <!-- The number of messages for which the PolicyEvaluatedType was applied. --> <xs:element name="count" type="xs:integer" minOccurs="1" maxOccurs="1"/> <!-- The DMARC disposition applied to matching messages. --> <xs:element name="policy_evaluated" type="PolicyEvaluatedType" minOccurs="1" maxOccurs="1"/> <xs:element name="extensions" type="ExtensionType" minOccurs="0" maxOccurs"unbounded"/> <xs:element name="source_heloname" type="xs:string" minOccurs="0" maxOccurs="1"/> <xs:element name="source_reversedns" type="xs:string" minOccurs="0" maxOccurs="1"/> </xs:all> </xs:complexType>
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
