Re: [dmarc-discuss] [EXTERNAL] Re: Mimecast and Office 365

2018-04-24 Thread Roland Turner via dmarc-discuss
Ah, in that case we've been talking at crossed purposes. I've just 
realised that Ivan's question ("Would O365 do DMARC checks for internal 
emails ie. O365 tenant employee to another O365 tenant employee?") is 
ambiguous:


 * I've assumed that he means: Would O365 do DMARC checks for internal
   emails ie. O365 tenant employee to (another O365 tenant) employee?",
   i.e. an employee of another tenant
 * You've assumed that he means: Would O365 do DMARC checks for
   internal emails ie. O365 tenant employee to another (O365 tenant
   employee)?", i.e. another employee of the same tenant

Ivan, if you're still following, which question are you asking?

- Roland





On 24/04/18 13:53, Terry Zink via dmarc-discuss wrote:

Okay, when I say "internal mail" I mean intra-tenant mail. Inter-tenant mail is 
basically the same as external mail from a customer perspective.

-Original Message-
From: Roland Turner <rol...@rolandturner.com>
Sent: Monday, April 23, 2018 9:58 PM
To: Terry Zink <tz...@microsoft.com>; dmarc-discuss@dmarc.org
Subject: [EXTERNAL] Re: [dmarc-discuss] Mimecast and Office 365

On 24/04/18 00:51, Terry Zink via dmarc-discuss wrote:


Failure reporting seems odd (because it's always legitimate) until
you recall that part of the purpose of failure reporting is to
discover errors by the domain registrant, particularly
including errors in the DNS zone file, which may or may not
be under Office 365 control

If Office 365 isn’t doing any DNS checks for SPF, DKIM, and DMARC for
internal email, then how would a DMARC report help with any of that?


On this line of reasoning, it would be necessary to perform those checks during 
message handling.

(I note that you refer here to "internal mail" and below to "inter-tenant 
communication". To be clear, I'm referring specifically to DMARC reporting - both failure and 
aggregate - for inter-tenant email, rather than for intra-tenant email.)

Aggregate reporting likewise seems like something that would make
sense for inter-tenant communication

Inter-tenant communication is treated the same (more or less) as an
inbound message that originates from outside the service, so any DMARC
reports that are sent would not different between tenant-to-tenant
mail vs. outside-to-Office365 mail.


So long as the checks are being performed, yes, this is what I'm suggesting.

You might reasonably object that the incremental benefit in performing these 
tests is too small to warrant performing them of course (presumably there are 
no large mailing-list operators using Office 365).


Does Office 365 DKIM sign inter-tenant email?

Yes. Inter-tenant mail is treated the same for DKIM purposes as
Tenant-to-external mail. Our customer guidance is here for DKIM:
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftechn
et.microsoft.com%2Fen-us%2Flibrary%2Fmt695945(v%3Dexchg.150).aspx
=02%7C01%7Ctzink%40microsoft.com%7Cabbbe14f6bb34e45729108d5a9a007be%7C
72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636601427147563145=q0
XGyDUlS9dz9n25T5IrxtsbzyX6FIXTstxD7ZI0Exw%3D=0


Great.

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



___
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] [EXTERNAL] Re: Mimecast and Office 365

2018-04-24 Thread Terry Zink via dmarc-discuss
No short-term plans. Although Advanced Threat Protection will be able to 
approximate some of it using our reporting via the Get-PhishFilterPolicy 
cmdlet. They could use:

$file = "SpoofedSendersImpersonatingMyDomain.csv"
Get-PhishFilterPolicy -Detailed -SpoofAllowBlocklist -SpoofType Internal | 
Export-CSV $file

See 
https://docs.microsoft.com/en-us/powershell/module/exchange/advanced-threat-protection/Get-PhishFilterPolicy?view=exchange-ps

There are some improvements coming to that report as well.

It's not a DMARC report and has a lot less meta-data, but does give some of the 
key information if a DMARC aggregator wants to parse it out. This could be sent 
to a 3rd party if an admin wanted to write a script to do this by combining the 
following:

1. Connect to Exchange Online using Powershell, 
https://docs.microsoft.com/en-us/powershell/exchange/exchange-online/connect-to-exchange-online-powershell/connect-to-exchange-online-powershell?view=exchange-ps

2. Run that script above

3. Send email via Powershell to the 3rd party aggregator, 
https://practical365.com/exchange-server/powershell-how-to-send-email/

--Terry

-Original Message-
From: Randal Pinto <ran...@redsift.io> 
Sent: Tuesday, April 24, 2018 12:32 AM
To: Terry Zink <tz...@microsoft.com>; dmarc-discuss@dmarc.org
Subject: Re: [dmarc-discuss] [EXTERNAL] Re: Mimecast and Office 365

Hi Terry,

Other Microsoft properties such as LinkedIn and Outlook generate DMARC reports, 
is there a plan to roll this out to Office 365? 

We find that a number of people who embark on implementing DMARC and have stats 
from their gateways expect to see a similar number (or close enough) in their 
DMARC reports and by Microsoft being a common destination it makes a 
significant difference on the numbers. It also means that users don’t benefit 
from forensics, Microsoft being one of a few who support this part of the spec.

Best,
Randal


> On 24 Apr 2018, at 06:53, Terry Zink via dmarc-discuss 
> <dmarc-discuss@dmarc.org> wrote:
> 
> Okay, when I say "internal mail" I mean intra-tenant mail. Inter-tenant mail 
> is basically the same as external mail from a customer perspective.
> 
> -Original Message-
> From: Roland Turner <rol...@rolandturner.com>
> Sent: Monday, April 23, 2018 9:58 PM
> To: Terry Zink <tz...@microsoft.com>; dmarc-discuss@dmarc.org
> Subject: [EXTERNAL] Re: [dmarc-discuss] Mimecast and Office 365
> 
> On 24/04/18 00:51, Terry Zink via dmarc-discuss wrote:
> 
>>> Failure reporting seems odd (because it's always legitimate) until 
>>> you recall that part of the purpose of failure reporting is to 
>>> discover errors by the domain registrant, particularly
>> 
>>> including errors in the DNS zone file, which may or may not
>> 
>>> be under Office 365 control
>> 
>> If Office 365 isn’t doing any DNS checks for SPF, DKIM, and DMARC for 
>> internal email, then how would a DMARC report help with any of that?
>> 
> 
> On this line of reasoning, it would be necessary to perform those checks 
> during message handling.
> 
> (I note that you refer here to "internal mail" and below to 
> "inter-tenant communication". To be clear, I'm referring specifically 
> to DMARC reporting - both failure and aggregate - for inter-tenant 
> email, rather than for intra-tenant email.)
>> 
>>> Aggregate reporting likewise seems like something that would make 
>>> sense for inter-tenant communication
>> 
>> Inter-tenant communication is treated the same (more or less) as an 
>> inbound message that originates from outside the service, so any 
>> DMARC reports that are sent would not different between 
>> tenant-to-tenant mail vs. outside-to-Office365 mail.
>> 
> 
> So long as the checks are being performed, yes, this is what I'm suggesting.
> 
> You might reasonably object that the incremental benefit in performing these 
> tests is too small to warrant performing them of course (presumably there are 
> no large mailing-list operators using Office 365).
> 
>>> Does Office 365 DKIM sign inter-tenant email?
>> 
>> Yes. Inter-tenant mail is treated the same for DKIM purposes as 
>> Tenant-to-external mail. Our customer guidance is here for DKIM:
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftech
>> n 
>> et.microsoft.com%2Fen-us%2Flibrary%2Fmt695945(v%3Dexchg.150).aspx
>> a 
>> =02%7C01%7Ctzink%40microsoft.com%7Cabbbe14f6bb34e45729108d5a9a007be%7
>> C
>> 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636601427147563145=q
>> 0
>> XGyDUlS9dz9n25T5IrxtsbzyX6FIXTstxD7ZI0Exw%3D=0
>> 
> 
> Great.
> 
> - Roland
> 
> 
> _

Re: [dmarc-discuss] [EXTERNAL] Re: Mimecast and Office 365

2018-04-24 Thread Randal Pinto via dmarc-discuss
Hi Terry,

Other Microsoft properties such as LinkedIn and Outlook generate DMARC reports, 
is there a plan to roll this out to Office 365? 

We find that a number of people who embark on implementing DMARC and have stats 
from their gateways expect to see a similar number (or close enough) in their 
DMARC reports and by Microsoft being a common destination it makes a 
significant difference on the numbers. It also means that users don’t benefit 
from forensics, Microsoft being one of a few who support this part of the spec.

Best,
Randal


> On 24 Apr 2018, at 06:53, Terry Zink via dmarc-discuss 
> <dmarc-discuss@dmarc.org> wrote:
> 
> Okay, when I say "internal mail" I mean intra-tenant mail. Inter-tenant mail 
> is basically the same as external mail from a customer perspective.
> 
> -Original Message-
> From: Roland Turner <rol...@rolandturner.com> 
> Sent: Monday, April 23, 2018 9:58 PM
> To: Terry Zink <tz...@microsoft.com>; dmarc-discuss@dmarc.org
> Subject: [EXTERNAL] Re: [dmarc-discuss] Mimecast and Office 365
> 
> On 24/04/18 00:51, Terry Zink via dmarc-discuss wrote:
> 
>>> Failure reporting seems odd (because it's always legitimate) until 
>>> you recall that part of the purpose of failure reporting is to 
>>> discover errors by the domain registrant, particularly
>> 
>>> including errors in the DNS zone file, which may or may not
>> 
>>> be under Office 365 control
>> 
>> If Office 365 isn’t doing any DNS checks for SPF, DKIM, and DMARC for 
>> internal email, then how would a DMARC report help with any of that?
>> 
> 
> On this line of reasoning, it would be necessary to perform those checks 
> during message handling.
> 
> (I note that you refer here to "internal mail" and below to "inter-tenant 
> communication". To be clear, I'm referring specifically to DMARC reporting - 
> both failure and aggregate - for inter-tenant email, rather than for 
> intra-tenant email.)
>> 
>>> Aggregate reporting likewise seems like something that would make 
>>> sense for inter-tenant communication
>> 
>> Inter-tenant communication is treated the same (more or less) as an 
>> inbound message that originates from outside the service, so any DMARC 
>> reports that are sent would not different between tenant-to-tenant 
>> mail vs. outside-to-Office365 mail.
>> 
> 
> So long as the checks are being performed, yes, this is what I'm suggesting.
> 
> You might reasonably object that the incremental benefit in performing these 
> tests is too small to warrant performing them of course (presumably there are 
> no large mailing-list operators using Office 365).
> 
>>> Does Office 365 DKIM sign inter-tenant email?
>> 
>> Yes. Inter-tenant mail is treated the same for DKIM purposes as 
>> Tenant-to-external mail. Our customer guidance is here for DKIM:
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftechn
>> et.microsoft.com%2Fen-us%2Flibrary%2Fmt695945(v%3Dexchg.150).aspx
>> =02%7C01%7Ctzink%40microsoft.com%7Cabbbe14f6bb34e45729108d5a9a007be%7C
>> 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636601427147563145=q0
>> XGyDUlS9dz9n25T5IrxtsbzyX6FIXTstxD7ZI0Exw%3D=0
>> 
> 
> Great.
> 
> - 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)

-- 


Red Sift <https://redsift.com/> is the power behind OnDMARC 
<https://ondmarc.com/>


You can find us at 20 Air Street,  
<https://www.google.co.uk/maps/place/20+Air+St,+Soho,+London+W1B+5DL/@51.5106005,-0.1386838,17z/data=!3m1!4b1!4m5!3m4!1s0x487604d43ec83ee3:0x6c9ba83f8be1d3bc!8m2!3d51.5105972!4d-0.1364951>4th
 
Floor - Wayra, London, W1B 5AN, UK 
<https://www.google.co.uk/maps/place/20+Air+St,+Soho,+London+W1B+5DL/@51.5106005,-0.1386838,17z/data=!3m1!4b1!4m5!3m4!1s0x487604d43ec83ee3:0x6c9ba83f8be1d3bc!8m2!3d51.5105972!4d-0.1364951>


Or follow us at @redsift <https://twitter.com/redsift> and @getondmarc 
<https://twitter.com/getondmarc>


If you have a couple of minutes spare 
why not... 

Read about how we helped ADS beat phishing in the UK Defence 
Journal 
<https://ukdefencejournal.org.uk/ads-group-solves-email-deliverability-issues-combats-phishing-ondmarc/>.


Or check out our latest advice 
<https://blog.ondmarc.com/?utm_source=rs_email_signature_medium=email> 
on boosting email deliverability and beating phishing.


Red Sift is a 
limited company registered in England and Wales. Re

Re: [dmarc-discuss] [EXTERNAL] Re: Mimecast and Office 365

2018-04-23 Thread Terry Zink via dmarc-discuss
Okay, when I say "internal mail" I mean intra-tenant mail. Inter-tenant mail is 
basically the same as external mail from a customer perspective.

-Original Message-
From: Roland Turner <rol...@rolandturner.com> 
Sent: Monday, April 23, 2018 9:58 PM
To: Terry Zink <tz...@microsoft.com>; dmarc-discuss@dmarc.org
Subject: [EXTERNAL] Re: [dmarc-discuss] Mimecast and Office 365

On 24/04/18 00:51, Terry Zink via dmarc-discuss wrote:

> > Failure reporting seems odd (because it's always legitimate) until 
> > you recall that part of the purpose of failure reporting is to 
> > discover errors by the domain registrant, particularly
>
> > including errors in the DNS zone file, which may or may not
>
> > be under Office 365 control
>
> If Office 365 isn’t doing any DNS checks for SPF, DKIM, and DMARC for 
> internal email, then how would a DMARC report help with any of that?
>

On this line of reasoning, it would be necessary to perform those checks during 
message handling.

(I note that you refer here to "internal mail" and below to "inter-tenant 
communication". To be clear, I'm referring specifically to DMARC reporting - 
both failure and aggregate - for inter-tenant email, rather than for 
intra-tenant email.)
>
> > Aggregate reporting likewise seems like something that would make 
> > sense for inter-tenant communication
>
> Inter-tenant communication is treated the same (more or less) as an 
> inbound message that originates from outside the service, so any DMARC 
> reports that are sent would not different between tenant-to-tenant 
> mail vs. outside-to-Office365 mail.
>

So long as the checks are being performed, yes, this is what I'm suggesting.

You might reasonably object that the incremental benefit in performing these 
tests is too small to warrant performing them of course (presumably there are 
no large mailing-list operators using Office 365).

> > Does Office 365 DKIM sign inter-tenant email?
>
> Yes. Inter-tenant mail is treated the same for DKIM purposes as 
> Tenant-to-external mail. Our customer guidance is here for DKIM:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftechn
> et.microsoft.com%2Fen-us%2Flibrary%2Fmt695945(v%3Dexchg.150).aspx
> =02%7C01%7Ctzink%40microsoft.com%7Cabbbe14f6bb34e45729108d5a9a007be%7C
> 72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636601427147563145=q0
> XGyDUlS9dz9n25T5IrxtsbzyX6FIXTstxD7ZI0Exw%3D=0
>

Great.

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