0

I run the the email for several domains and receive the domain reports on their behalf. Google is our email provider.

enterprise.protection.outlook.com, sends aggregate reports with an envelope_to header, revealing to whom the email is being sent. This is none of my business, and it makes me uncomfortable seeing this information, since it appears that several small businesses are using Microsoft's services.

Long term, is this the new standard that this type of information is going to be released to administrators? Is there any way to request these reports do not contain this information?

I appreciate the utility of dmarc, but it makes me less inclined to use the service.

Email headers:

    <identifiers>
      <envelope_to>receiver.com</envelope_to>
      <envelope_from>sender.com</envelope_from>
      <header_from>sender.com</header_from>
    </identifiers>

It looks like there have been discussions in the past on the dmarc mailing list, with people expressing concerns similar to my own:

https://www.mail-archive.com/[email protected]/msg07751.html

Improve this question
3
  • This question makes little sense. As the email admin, you need to see the traffic flow for troubleshooting. And since you configured the admin reports to be sent to you, then you get the data. There is no "privacy" breach on Microsoft's side. You opted to receive troubleshooting data ...
    – schroeder ♦
    May 14 at 8:34
  • as far as i can tell, Microsoft is the only company providing this information that has no effect on my ability to administer my outgoing mail. envelope_from is reasonable, envelope_to is none of my business
    – Juan
    May 14 at 15:55
  • 1
    I don't have examples readily available, but certainly MS is not the only party to include the envelope_to field in the aggregate reports. It might help you identify the mail flow that is failing authentication, by examining logs from multiple services. I find it very helpful myself.
    – Reinto
    May 16 at 10:32

2 Answers 2

Reset to default
1

The envelope_to field is optional for the sending service to include in the aggregate reports (in XML format) as detailed by de minOccurs="0" part of the element explains in appendix C: DMARC rfc

While it is optional it will help in troubleshooting failing emails. The information you assume from it, "party A is using Mailbox Service Provider B" is not really a hidden secret. If you query a domain's MX and SPF records, you can see exactly how a small business or any other entity sends and receives emails.

I do agree that adding this information to the aggregate reports and considering that many businesses and other entities use third party DMARC report visualizing tools, that these third parties receive a ton of information about mail flows between different entities. But that's another issue entirely.

Improve this answer
2
  • My concern is knowledge of the businesses my customers may be dealing with. My need for information ends at the entity processing the email.
    – Juan
    May 17 at 15:41
  • You may have a very specific relationship with your customers where you receive reports for their domains? The fact that MS and others include the envelope_to in the aggregate reports is well within the specifications of the RFC. So, why would you receive their reports anyways if you don't want to investigate failures with all the available information? Perhaps you using the wrong tools for your assignment / goal.
    – Reinto
    May 18 at 16:18
-1

DMARC RFC:

"These reports SHOULD include as much of the message and message header as is reasonable to support the Domain Owner's investigation into what caused the message to fail authentication and track down the sender."

DMARC Aggregate Reporting RFC

<xs:complexType name="IdentifierType">
 <xs:all>
  <!-- The envelope recipient domain. -->
  <xs:element name="envelope_to" type="xs:string"     <-- relevant bit
        minOccurs="0" maxOccurs="1"/>
  <!-- The RFC5321.MailFrom domain or, if that value is empty,
       the RFC5321.Helo domain. -->
  <xs:element name="envelope_from" type="xs:string"
        minOccurs="0" maxOccurs="1"/>
  <!-- The RFC5322.From domain. -->
  <xs:element name="header_from" type="xs:string"
        minOccurs="1" maxOccurs="1"/>
 </xs:all>
</xs:complexType>

So, there is nothing wrong with MS providing the to field. It's all part of the RFCs. And if I was troubleshooting DMARC, I'd want to know the full mail flow path to rule out all factors.

So, from all the RFCs, forensic and aggregate, this is not "new" but simply optional.

"Is there any way to request these reports do not contain this information."

This is a question solely for the sender of the report.

Improve this answer
4
  • I don't believe the envelope_to is reasonable or helps the investigation. The relevant bit in my case is the the email was sent to a domain using Microsoft's email services. Knowledge of the actual domain is none of my business.
    – Juan
    May 14 at 18:10
  • 1
    The report you are presenting is not the xml report that I am receiving. I have added the relevant fields in the report to my original post. It is unclear to me how these fields are helpful when enterprise.protection.outlook.com is reporting the email as being successfully delivered.
    – Juan
    May 14 at 18:33
  • I don't know how else to explain this. You are asking for forensic reports, yes? And that includes everything, fail or no. Being able to investigate why things succeed can be just as useful when things are going wrong. In short, nothing is wrong.
    – schroeder ♦
    May 14 at 19:54
  • Aggregate reports also have an envelope_to
    – schroeder ♦
    May 19 at 21:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .