Hello Roland, it would not make sense for Microsoft in this scenario to send reports back as they will be wrong anyway. It would be ideal if Mimecast in this case introduced the reporting functionality so senders have visibility into their traffic. However, not sure if Mimecast are at all considering it. I am sure a lot of their customers have requested it but for the moment there is no indication that this will happen.
> On 19 Apr 2018, at 11:32, dmarc-discuss-requ...@dmarc.org wrote: > > Send dmarc-discuss mailing list submissions to > dmarc-discuss@dmarc.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://dmarc.org/mailman/listinfo/dmarc-discuss > or, via email, send a message with subject or body 'help' to > dmarc-discuss-requ...@dmarc.org > > You can reach the person managing the list at > dmarc-discuss-ow...@dmarc.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of dmarc-discuss digest..." > > > Today's Topics: > > 1. Re: dmarc-discuss Digest, Vol 72, Issue 2 (Roland Turner) > 2. Re: dmarc-discuss Digest, Vol 72, Issue 2 (Roland Turner) > 3. my agg. reports (A. Schulze) > 4. Re: my agg. reports (Juri Haberland) > 5. Re: my agg. reports (Alessandro Vesely) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 19 Apr 2018 08:33:42 +0800 > From: Roland Turner <rol...@rolandturner.com> > To: dmarc-discuss@dmarc.org > Subject: Re: [dmarc-discuss] dmarc-discuss Digest, Vol 72, Issue 2 > Message-ID: <dd94cae9-7e7b-ff49-839d-96e50fe07...@rolandturner.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > On 19/04/18 00:48, Ivan Kovachev via dmarc-discuss wrote: > >> I found this on Microsoft's website: >> >> "If you have configured your domain's MX records where EOP is not the >> first entry, DMARC failures will not be enforced for your domain. >> If you're an Office 365 customer, and your domain's primary MX record >> does not point to EOP, you will not get the benefits of DMARC. For >> example, DMARC won't work if you point the MX record to your >> on-premises mail server and then route email to EOP by using a >> connector. " >> I guess this is why we are currently not seeing any reports being sent >> by Office 365 if it has Mimecast in front of it and as part of the MX >> record for receiving domain. > > This is a neat feature: why require customers to separately configure > trusted relays when they've already voted with their MX records? > > Only the perimeter (i.e. MX) system - or set of systems under the same > administrative control - should be enforcing DMARC: > > * SPF will always be broken for a downstream system (because it will > see the IP address of the upstream system) > * DKIM will potentially be broken by the upstream system (always in > Mimecast's case) > > Reporting is probably a no also, because there's no reason at all for > Microsoft to disclose this information; from the perspective of the > email system the Mimecast->Microsoft transition is an internal step. Are > you looking for such reporting to occur? > > - Roland > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://dmarc.org/pipermail/dmarc-discuss/attachments/20180419/dde6cab7/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Thu, 19 Apr 2018 08:35:38 +0800 > From: Roland Turner <rol...@rolandturner.com> > To: Al Iverson <aiver...@wombatmail.com>, dmarc-discuss@dmarc.org > Subject: Re: [dmarc-discuss] dmarc-discuss Digest, Vol 72, Issue 2 > Message-ID: <322a635a-d3f6-2417-6223-b92a6da6e...@rolandturner.com> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > As they're purely internal to a single organisation (the receiving > domain, which happens to have outsourced to Mimecast and Microsoft), > there's no reason to record the failures but, yes, > Authentication-Results: headers might reasonably be expected to contain > this information. ARC headers also as they start to appear. > > - Roland > > ------------------------------------------------------------------------ > > On 19/04/18 01:36, Al Iverson via dmarc-discuss wrote: >> So in this scenario, how is O365 denoting the DMARC failures? Is it >> alerting, or is it something visible only when viewing the message >> headers? >> >> On Wed, Apr 18, 2018 at 12:48 PM, Ivan Kovachev via dmarc-discuss >> <dmarc-discuss@dmarc.org> wrote: >>> Hello Roland, >>> >>> thank you for the reply. >>> >>> I found this on Microsoft's website: >>> >>> "If you have configured your domain's MX records where EOP is not the first >>> entry, DMARC failures will not be enforced for your domain. >>> If you're an Office 365 customer, and your domain's primary MX record does >>> not point to EOP, you will not get the benefits of DMARC. For example, DMARC >>> won't work if you point the MX record to your on-premises mail server and >>> then route email to EOP by using a connector. " >>> I guess this is why we are currently not seeing any reports being sent by >>> Office 365 if it has Mimecast in front of it and as part of the MX record >>> for receiving domain. >>> >>> On 12 Apr 2018, at 20:00, dmarc-discuss-requ...@dmarc.org wrote: >>> >>> Send dmarc-discuss mailing list submissions to >>> dmarc-discuss@dmarc.org >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> http://dmarc.org/mailman/listinfo/dmarc-discuss >>> or, via email, send a message with subject or body 'help' to >>> dmarc-discuss-requ...@dmarc.org >>> >>> You can reach the person managing the list at >>> dmarc-discuss-ow...@dmarc.org >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of dmarc-discuss digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: Mimecast and Office 365 (Roland Turner) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Thu, 12 Apr 2018 15:57:20 +0800 >>> From: Roland Turner <rol...@rolandturner.com> >>> To: dmarc-discuss@dmarc.org >>> Subject: Re: [dmarc-discuss] Mimecast and Office 365 >>> Message-ID: <7a30d43c-5cd2-9da2-aff9-af92cc71c...@rolandturner.com> >>> Content-Type: text/plain; charset="utf-8"; Format="flowed" >>> >>> On 11/04/18 22:07, Ivan Kovachev via dmarc-discuss wrote: >>> >>> Hello guys, >>> >>> I have three questions for you that I am unsure about and hoping that >>> someone at Microsoft will be able to help: >>> >>> First two questions are related to Mimecast acting as inbound security >>> gateway to O365: >>> >>> 1. When Mimecast acts as inbound gateway solution and it receives an >>> email, it does DMARC checks and lets the email through to O365 >>> environment. Even if an email passes DMARC checks at Mimecast and the >>> email is let through, then O365 also seems to also be doing DMARC >>> checks but both SPF and DKIM fail because of the change that Mimecast >>> does. As a results DMARC fails. My questions is, what is the best >>> practice here in this scenario? Is there a way to turn off DMARC >>> checks at O365? Mimecast suggest that it is whitelisted in O365 but >>> that means that all the spam will be let through as well. >>> >>> >>> DMARC checking should only occur at the host referred to be the MX >>> record as SPF is still relevant for at least some email. I believe >>> Office 365 has a trusted inbound relays option (i.e. Office 365 trusts >>> the specified hosts to filter their email) although I can't quickly find it. >>> >>> Mimecast is apparently unwilling to change their service to stop >>> damaging incoming messages that don't breach the policies being enforced >>> (they unconditionally unpack and then repack every message, rather than >>> only those whose contents they have reason to modify). >>> >>> 2. Would O365 send DMARC reports back to the sender in the above case? >>> And, if O365 sends DMARC reports back to the sender then emails will >>> be shown as originating from Mimecast but failing DMARC. >>> >>> >>> Yes and yes if you've not listed Mimecast as a trusted inbound relay. >>> (Assuming that the trusted inbound relays setting is not a figment of my >>> imagination, one would hope that Office 365 would not set feedback in >>> this case.) >>> >>> 3. Would O365 do DMARC checks for internal emails ie. O365 tenant >>> employee to another O365 tenant employee? And would it send DMARC >>> reports in this case? >>> >>> >>> Yes and hopefully yes. >>> >>> - Roland >>> -------------- next part -------------- >>> An HTML attachment was scrubbed... >>> URL: >>> <http://dmarc.org/pipermail/dmarc-discuss/attachments/20180412/52e84e2b/attachment-0001.html> >>> >>> ------------------------------ >>> >>> Subject: Digest Footer >>> >>> _______________________________________________ >>> dmarc-discuss mailing list >>> dmarc-discuss@dmarc.org >>> http://www.dmarc.org/mailman/listinfo/dmarc-discuss >>> >>> NOTE: Participating in this list means you agree to the DMARC Note Well >>> terms (http://www.dmarc.org/note_well.html) >>> >>> >>> ------------------------------ >>> >>> End of dmarc-discuss Digest, Vol 72, Issue 2 >>> ******************************************** >>> >>> >>> >>> _______________________________________________ >>> dmarc-discuss mailing list >>> dmarc-discuss@dmarc.org >>> http://www.dmarc.org/mailman/listinfo/dmarc-discuss >>> >>> NOTE: Participating in this list means you agree to the DMARC Note Well >>> terms (http://www.dmarc.org/note_well.html) >> >> > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > <http://dmarc.org/pipermail/dmarc-discuss/attachments/20180419/241485e3/attachment-0001.html> > > ------------------------------ > > Message: 3 > Date: Thu, 19 Apr 2018 07:55:57 +0200 > From: "A. Schulze" <s...@andreasschulze.de> > To: dmarc-discuss@dmarc.org > Subject: [dmarc-discuss] my agg. reports > Message-ID: > <20180419075557.horde.plkcjgkusaaipgawudbm...@andreasschulze.de> > Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes > > > Hello @all, > > since some days aggregated reports we generate using an other software: rspamd > These reports are invisible at dmarcian.com. I would like to ask the > group to review > my reports if they are syntactical valid. > > Thanks! > Andreas > > > > ------------------------------ > > Message: 4 > Date: Thu, 19 Apr 2018 08:30:04 +0200 > From: Juri Haberland <j...@sapienti-sat.org> > To: dmarc-discuss@dmarc.org > Subject: Re: [dmarc-discuss] my agg. reports > Message-ID: <9f485af46c691f43f0124288a657a...@sapienti-sat.org> > Content-Type: text/plain; charset=US-ASCII; format=flowed > > On 2018-04-19 07:55, A. Schulze via dmarc-discuss wrote: >> Hello @all, > > Hello Andreas, > >> since some days aggregated reports we generate using an other software: >> rspamd >> These reports are invisible at dmarcian.com. I would like to ask the >> group to review >> my reports if they are syntactical valid. > > This is what I found: > - wrong MIME type: expected: text/xml (.xml); found: application/xml > (.xml) > - missing <?xml version="1.0" encoding="UTF-8" ?> at the top > - not gziped > > [btw. the SPF result seems wrong: "none" instead of "pass" for a mail > from the opendmarc-users ML] > > > Juri > > > ------------------------------ > > Message: 5 > Date: Thu, 19 Apr 2018 12:32:26 +0200 > From: Alessandro Vesely <ves...@tana.it> > To: dmarc-discuss@dmarc.org > Subject: Re: [dmarc-discuss] my agg. reports > Message-ID: <5f7ce17e-7d4c-e70b-9b7c-f93ee11d0...@tana.it> > Content-Type: text/plain; charset=us-ascii > > Hi > > On Thu 19/Apr/2018 08:30:04 +0200 Juri Haberland via dmarc-discuss wrote: >> On 2018-04-19 07:55, A. Schulze via dmarc-discuss wrote: >>> since some days aggregated reports we generate using an other software: >>> rspamd These reports are invisible at dmarcian.com. I would like to ask >>> the group to review my reports if they are syntactical valid. > Yeah, there seem to be no DMARC report validators around... > >> This is what I found: >> - wrong MIME type: expected: text/xml (.xml); found: application/xml (.xml) > > I found text/xml as required > >> - missing <?xml version="1.0" encoding="UTF-8" ?> at the top > > I had that. However, I missed the <version> element inside <feedback>. > > >> - not gziped > > Although this is optional, I think that's the reason why I don't "see" your > reports. In addition, they're not pretty printed. > > If I were you, I'd use BCC: to address dmarc-send. > > hth > Ale > -- > > > > > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > dmarc-discuss mailing list > dmarc-discuss@dmarc.org > http://www.dmarc.org/mailman/listinfo/dmarc-discuss > > NOTE: Participating in this list means you agree to the DMARC Note Well terms > (http://www.dmarc.org/note_well.html) > > > ------------------------------ > > End of dmarc-discuss Digest, Vol 72, Issue 5 > ******************************************** _______________________________________________ dmarc-discuss mailing list dmarc-discuss@dmarc.org http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
