Hi Simon,
Many thanks for following this up!
I'm not in a position to name the Mimecast customer in question, but
will certainly forward your message to them.
Their understanding was that the unpacking and repacking was
unconditional, that Mimecast provided no option to turn it off for
specified recipients whose live mailboxes were hosted elsewhere (there
was MTA-level forwarding happening within the customer's environment)
and for whom DKIM-preserving forwarding was therefore a requirement, the
only Mimecast features required for those particular users being upfront
spam filtering. In the test messages that I saw, Mimecast was making no
policy-relevant content changes at all, it was merely changing the body
encoding; this breaks DKIM signatures and therefore DMARC but has little
other practical effect.
A non-"body based" DKIM signature is essentially an invitation to phish,
as it allows an adversary to present - and have pass DKIM validation -
any body and attachments that they wish. It is technically possible to
sign headers only but this is not a widespread practice, and not an
obviously useful one.
The recent discussion on this list about internal DMARC checks appears
to have been a discussion at crossed purposes: internal to Office 365
vs. internal to a single tenant.
Regards,
- Roland
------------------------------------------------------------------------
On 25/04/18 16:08, Simon Tyler wrote:
Sorry for the slow response to the original Mimecast question. I want
to set the record straight on what Mimecast does to mail as it flows
through us and why.
Firstly, Mimecast does unpack and repack every message. This does
sometimes break DKIM signatures especially if they are body based. For
most of our customers we have to do this as we are making changes to
the message that require it. The reason varies but things like URL
rewriting, attachment stripping or conversion require it.
The unpack and repack is not unconditional. We have options that allow
for it to be disabled (with the side effect that certain features are
not available) and we also apply it automatically in some cases but
existence or breaking of a DKIM signature is not one of those cases.
For the vast majority of our customers this is entirely fine. Mimecast
is their gateway so all DMARC checks and signature additions are
performed at the Mimecast gateway and the fact that we break
signatures is not an issue. If customers are seeing signatures
breaking on outbound messages then they need to configure Mimecast to
sign outbound for them.
I hope that makes sense.
I am interested in the use case for the internal message DMARC checks.
If someone can clarify why that is useful then I would find that helpful.
Simon
Simon Tyler m: +44 7590 735958 www.mimecast.com
<http://www.mimecast.com/>
VP of Engineering and Product Research p: +44 207 847 8700 Address
click here <https://www.mimecast.com/company/contact/>
------------------------------------------------------------------------
Mimecast <https://www.mimecast.com/>
Linked In
<https://eu-api.mimecast.com/s/click/5JcCD0h33hgzzKa3ghEhB8vQDQlrUjHbWqSt8q1X-GRiu1pjzGgUjvX51ipVcHEfi407veySRYS5kBhdN0bsT58S2m5kuvuL5G1QxBg5zMwvdJ2tcwTpszBUHETfaV1TIrvfGXKPiz5e6aX0Rt4fpUJWUMm-9a8Vm_PqS5F3ewu8M2NheT3hwS2_-8dptduj5QF-gtjaRB2AAoxh8fgneg>
You Tube
<https://eu-api.mimecast.com/s/click/IKmtIWZgah9PkQKTA72V57uuNIoeDAQ9jfmxYCepHJMg07URWTHJKOdqNHSKabQoaDICTlhKDzamQmBCD7sYA5USyD4MDidqfjSQRx9q3_QhFhEMAUQJTA5Q4CPpF_RjYLDaYHBgzeWj3T3CjwEbd2ttnYf7UInxHIvXt8jMQ7M4aXf5jTUgIGQV8pfjYpinUWsThNMfSE_TxYg9ZhC-Fg>
Facebook
<https://eu-api.mimecast.com/s/click/oy6FsTS-W0rnavuyv2-6_FujHQ9QVkJ3YpW-meUQgOoIFPUealXotQk3clESBr7ZgLFDdHoXEMzVGa3tGG_0kPKkTidfmPFTUDFormLWUhcW_OD2cILI6a1ta-MyWNzyCNyzLv5WsEaD9XkLy-r3MlBO4fSf8ekzU0PaoVaZ7gs2M-IcOIG7t3-l95pyIzZC-ejr-CSar1Gyh63FHmD69w>
Blog
<https://eu-api.mimecast.com/s/click/gNXpRy8Di3hABeg9FCvOkHLoh2DkKAcPQwJcA_CqdxhxMpOnzpx_0xMQAgoYrfVGUhPyUzbfFx5MbOx1rkaPhXVPCRBYg4JXq_Wd9owjxjfh4R2PlEAcZSGpm-yAxDIQ-1-DXs8HNoBxB7OUVIfjBbm80zerQX9iyu2hUqSsBeorOQA5m0DSs02m-WfDE0D8tYPRnmcZcpyPxrm6LtXhAA>
Twitter
<https://eu-api.mimecast.com/s/click/F2A44qlyvx7D1oreXULOBeF2KhbL4WqwQhp4Y_6QFINiByB4X31v4uE_Xj80gVsi0rQBhK2HiZzaa9svYhwV3XVPCRBYg4JXq_Wd9owjxjfh4R2PlEAcZSGpm-yAxDIQ-1-DXs8HNoBxB7OUVIfjBbm80zerQX9iyu2hUqSsBeorOQA5m0DSs02m-WfDE0D8d8DVIvSvoVqw_eZJjoJstQ>
Want to learn more
<https://eu-api.mimecast.com/s/click/OBmVNlyQjIVMDExi6Ss0HGnI7zYxcMAdYFWUdfx5RenPnaV77Q53g0337wyC5JZ7NgERbwVjsyhdV0CDB4oLV-ZuiBP008BuFarXHxoZCZv9U9RNZEgMdwK60cgN7kRNnDih8wm207v0_A5XrJQCxPM7K4GafRPq63zp1vDRfC-IiwKJFAFWw7NclFhlb85kUlP7BnS2X8RCmJ7tllAw0w>
*Disclaimer*
The information contained in this communication from
*sty...@mimecast.com * sent at 2018-04-25 09:09:04 is confidential and
may be legally privileged. It is intended solely for use by
*rol...@rolandturner.com * and others authorized to receive it. If you
are not *rol...@rolandturner.com * you are hereby notified that any
disclosure, copying, distribution or taking action in reliance of the
contents of this information is strictly prohibited and may be unlawful.
This email message has been scanned for viruses by Mimecast. Mimecast
delivers a complete managed email solution from a single web based
platform. For more information please visit http://www.mimecast.com
*From: *dmarc-discuss <dmarc-discuss-boun...@dmarc.org> on behalf of
Roland Turner via dmarc-discuss <dmarc-discuss@dmarc.org>
*Reply-To: *Roland Turner <rol...@rolandturner.com>
*Date: *Thursday, 12 April 2018 at 09:07
*To: *"dmarc-discuss@dmarc.org" <dmarc-discuss@dmarc.org>
*Subject: *Re: [dmarc-discuss] Mimecast and Office 365
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
_______________________________________________
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)
