I was referring to the organizational domain of the MX server. I assumed that the MX server organization will also be the DMARC-evaluating organization, because DMARC is most useful if evaluated close to the network perimeter. When the aggregate report identifies the MX server organization accurately, then the report recipient can make at least a rough match between messages sent and messages reported. One recently-stated benefit of doing so is the ability to identify and exclude false reports, if they occur.
A possible counter-argument is that the report recipient does not need to match outbound messages to reports at all, he simply needs to know whether his messages passed SPF and DKIM at first hop. Based on both RFC 7489 and the current draft, I think the intent has always been to allow the match to be performed, whether for fraud detection or other purposes. The texts encourage every sender to use midnight GMT so that data can be consolidated, and the spec calls for the sending organization to identify itself. The problem is that the data currently being reported does not provide a reliable link to the MX Server name that is in the sender's outbound message logs. I am proposing that this be corrected by adding a new field. About EnvelopeTo By design, we do not want reporting to include the RFC5321.To domain. For server farms that host 1000s of domains, disaggregating by target domain would be an unreasonable burden and would aggravate the problem of overly large report files. For single-domain servers, it would be redundant. So it is only relevant for small-quantity domain owners like Yahoo. But since they have chosen to report at this level, I think we should acknowledge the practice so that if others follow suit, it is done consistently. Doug Foster On Wed, Nov 16, 2022 at 8:32 AM Brotman, Alex <[email protected]> wrote: > 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
