Re: [dmarc-discuss] Mimecast and Office 365

[Terry Zink via dmarc-discuss]

>> 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?

I didn’t see this answered, so answering it now.

Office 365 doesn’t do DMARC checks for internal emails since they don’t leave 
the network perimeter. Since no DMARC check is done, no DMARC report is sent 
(Office 365 doesn’t send DMARC reports anyway, but if it did, it wouldn’t in 
this case). There are some advanced reporting capabilities for Advanced Threat 
Protection customers that can quasi-approximate DMARC reports, and you could 
use Transport rules in the service to approximate a RUF report. But there’s no 
official DMARC reporting at this time.

--Terry

From: dmarc-discuss  On Behalf Of Roland 
Turner via dmarc-discuss
Sent: Thursday, April 12, 2018 12:57 AM
To: dmarc-discuss@dmarc.org
Subject: [EXTERNAL] 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)

Re: [dmarc-discuss] Multiple DKIM Signature Reporting in DMARC

[Scott Kitterman via dmarc-discuss]

On Sunday, April 22, 2018 02:12:33 PM Roland Turner via dmarc-discuss wrote:
> On 21/04/18 05:36, Scott Kitterman via dmarc-discuss wrote:
> > As most of you already know, the DCRUP working group is adding a new
> > signature algorithm to DKIM.  I have been sending dual
> > rsa-sha256/ed25519-sha256 signed mail for some time and I have notice an
> > oddity in DMARC reporting.> 
> > Typically, I'll see something like this XML snippet:
> > 
> > 
> > 
> > 
> > kitterman.com
> > pass
> > 201803r
> > 
> > 
> > 
> > 
> > kitterman.com
> > fail
> > 201803e
> > 
> > 
> > 
> > The first one is the rsa-sha256 signature and the second, marked fail, is
> > the ed25519-sha256 signature (I can tell based on the selector).  In all
> > cases I've checked, the correct (DMARC pass) result was obtained, but I
> > don't think this is the best way to report it.
> 
> It would be helpful for the receiver to explain that the problem is an
> interoperability one rather than an asserted failure of an implemented
> algorithm, certainly.
> 
> > RFC 6376 says:
> >> 3.3.4.  Other Algorithms
> >> 
> >> Other algorithms MAY be defined in the future.  Verifiers MUST ignore
> >> any signatures using algorithms that they do not implement.
> > 
> > I'm not sure reporting a failure is consistent with "MUST ignore".  In any
> > case, I think it would be useful to distinguish between DKIM evaluation
> > failed and not evaluated due to unknown algorithm in DMARC reporting.
> 
> There are half a dozen things which must be ignored if not supported
> (canonicalisations, etc.), but the obligation to ignore doesn't appear
> to imply an obligation not to report by whatever means are appropriate,
> only that the ignored elements must be removed from consideration prior
> to computing a pass.
> 
> More directly, in 6.3 Interpret Results/Apply Local Policy:
> > If the email cannot be verified, then it SHOULD be treated the same
> > as all unverified email, regardless of whether or not it looks like
> > it was signed.
> 
> This would appear to encourage treating 3.3.4 cases in the same way as
> all unverified email, i.e. reporting a fail, as the example you quote
> does. I do note that RFC 7601 - whose results RFC 7489 uses -
> establishes separate criteria for none, fail, policy, and neutral. It
> might be argued that neutral is a better fit for reporting the use of a
> signature algorithm not supported by the verifier:
> 
> none:  The message was not signed.
> 
> pass:  The message was signed, the signature or signatures were
>acceptable to the ADMD, and the signature(s) passed verification
>tests.
> 
> fail:  The message was signed and the signature or signatures were
>acceptable to the ADMD, but they failed the verification test(s).
> 
> policy:  The message was signed, but some aspect of the signature or
>signatures was not acceptable to the ADMD.
> 
> neutral:  The message was signed, but the signature or signatures
>contained syntax errors or were not otherwise able to be
>processed.  This result is also used for other failures not
>covered elsewhere in this list.
> 
> 
> Would using neutral with some explanatory text in a human_result element
> suit, or would you advocate the addition of "unsupported" (or similar)
> to 7601 and 7489?

I think neutral is reasonable.  I'd add to the definition above that the 
signature was not used for DMARC evaluation.  Neutral is what multiple 
implementations already report in their authentication results header fields 
for these signatures:

Authentication-Results: mx.google.com;
   dkim=neutral (no key) header.i=@kitterman.com header.s=201803e 
header.b=hxFQlnEt;

Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral
 reason="invalid (unsupported algorithm ed25519-sha256)"
 header.d=kitterman.com header.b=INr2EzUJ;

Scott K


___
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)

Re: [dmarc-discuss] Multiple DKIM Signature Reporting in DMARC

[Roland Turner via dmarc-discuss]

On 21/04/18 05:36, Scott Kitterman via dmarc-discuss wrote:


As most of you already know, the DCRUP working group is adding a new signature
algorithm to DKIM.  I have been sending dual rsa-sha256/ed25519-sha256 signed
mail for some time and I have notice an oddity in DMARC reporting.

Typically, I'll see something like this XML snippet:



kitterman.com
pass
201803r


kitterman.com
fail
201803e


The first one is the rsa-sha256 signature and the second, marked fail, is the
ed25519-sha256 signature (I can tell based on the selector).  In all cases
I've checked, the correct (DMARC pass) result was obtained, but I don't think
this is the best way to report it.


It would be helpful for the receiver to explain that the problem is an 
interoperability one rather than an asserted failure of an implemented 
algorithm, certainly.



RFC 6376 says:


3.3.4.  Other Algorithms

Other algorithms MAY be defined in the future.  Verifiers MUST ignore
any signatures using algorithms that they do not implement.

I'm not sure reporting a failure is consistent with "MUST ignore".  In any
case, I think it would be useful to distinguish between DKIM evaluation failed
and not evaluated due to unknown algorithm in DMARC reporting.


There are half a dozen things which must be ignored if not supported 
(canonicalisations, etc.), but the obligation to ignore doesn't appear 
to imply an obligation not to report by whatever means are appropriate, 
only that the ignored elements must be removed from consideration prior 
to computing a pass.


More directly, in 6.3 Interpret Results/Apply Local Policy:


If the email cannot be verified, then it SHOULD be treated the same
as all unverified email, regardless of whether or not it looks like
it was signed.


This would appear to encourage treating 3.3.4 cases in the same way as 
all unverified email, i.e. reporting a fail, as the example you quote 
does. I do note that RFC 7601 - whose results RFC 7489 uses - 
establishes separate criteria for none, fail, policy, and neutral. It 
might be argued that neutral is a better fit for reporting the use of a 
signature algorithm not supported by the verifier:


   none:  The message was not signed.

   pass:  The message was signed, the signature or signatures were
  acceptable to the ADMD, and the signature(s) passed verification
  tests.

   fail:  The message was signed and the signature or signatures were
  acceptable to the ADMD, but they failed the verification test(s).

   policy:  The message was signed, but some aspect of the signature or
  signatures was not acceptable to the ADMD.

   neutral:  The message was signed, but the signature or signatures
  contained syntax errors or were not otherwise able to be
  processed.  This result is also used for other failures not
  covered elsewhere in this list.


Would using neutral with some explanatory text in a human_result element 
suit, or would you advocate the addition of "unsupported" (or similar) 
to 7601 and 7489?


- 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)