Re: [mailop] Office 365 - Emails marked as not passing fraud detection

2017-11-28 Thread Lilium 


I can’t figure this one out so looking for some help from people in the 
know. One of our clients has a postfix mail relay server used for 
relaying emails from photocopiers/internal software systems out to the 
world.


Below I’ve pasted the headers of one. Office 365 / Outlook chucks them 
in the junk mail folder with a message “This sender failed our fraud 
detection checks and may not be who they appear to be.”


Hello Shane,
last week I had a similar issue and found this:
How to configure an Office 365 SMTP Relay Connector
https://support.happyfox.com/kb/article/522-office-365-smtp-relay-connector

Unfortunately I haven't been to make it work.

Regards
Andrea

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Office 365 - Emails marked as not passing fraud detection

2017-11-24 Thread Bill Cole 

On 23 Nov 2017, at 23:50 (-0500), Shane Clay via mailop wrote:

Bill - the email wasn't aimed at asking Microsoft for support on a 
public mailing list. It wasn't a technical support request at all. It 
was from a network person, separate the end user, looking into an 
issue which he is unforunately lumped with, who decided to ask a 
community of people who specialise in e-mail if they possibly see 
something that he didn't amongst a set of email headers. Surely that 
is an appropriate discussion to have amongst professionals.


Sure, and we discuss "Why is $BIGMAILBOXPROVIDER mishandling my mail?" 
all the time. It's useful, especially for non-customers of whichever 
$BIGMAILBOXPROVIDER is involved, but those conversations don't always 
result in rapid solutions or ANY solutions.


My points, put more directly, are:

1. The O365 admin for stcolumba.sa.edu.au or any other O365 domain has 
access to both self-service whitelisting tools and to direct Microsoft 
support which will be faster and more effective than getting suggestion 
from any set of fellow professionals. I say this based on being the 
primary O365 mail admin for multiple clients for over 4 years during 
which I handled multiple deliverability issues with a varied root 
causes, some of which I never was told by MS: they just fixed the 
problems.


2. The message you posted had identical To and From headers. That's a 
fairly strong heuristic spam indicator. It would be good to fix that, 
even if it's just to give users an informative sender name in their 
message list view.



Additionally: as Michael Peddemors noted, the PTR value for 
103.219.120.34 is a cause for suspicion per se because it is clearly 
IP-derived. Compounding that, the fact that the PTR value does not 
resolve as a hostname makes it even more suspect. If that IP is used for 
mail not going to O365, that mess will cause problems.



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Office 365 - Emails marked as not passing fraud detection

2017-11-24 Thread Michael Peddemors 

Thought I would point out as well..

This message was sent via Outlook to the list, and Outlook already 
marked your message as spam, which many other filtering systems will 
honour.  That header remained intact while being processed by the 
mailing list software at mailop.org.


x-forefront-antispam-report: SFV:SPM;...

And to the original problem, you might like to look at standard 'Best 
Practices for Email Operators'..


PTR:ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au

But in this case, it depends on how you expect that relay to function. 
If you configure the Postfix relay to use SMTP authentication through an 
email account at 'caznet.com.au', which is your provider correct? then 
you won't have any problems.  (Or use any SMTP provider where the client 
has an account)


However, if you want your relay to act as a true MTA, then you will have 
to conform to Best Practices.. eg change the PTR to be something like 
'server.customerdomain.com'. (The domain for the responsible party for 
the emails)


That default PTR you were assigned will probably be treated as an 
'unconfigured' source/device, and not an MTA by most spam methods to 
some extent or another..


But given that your corp ip was flagged, as well as the IP in question, 
it suggests that the reputation is either with your company, your 
network, or your domain, and not just that one IP Address.






On 17-11-23 07:59 PM, Shane Clay via mailop wrote:

I’d considered that.

This server has been around a long time (and the rdns hasn’t changed) 
and the problem has only just come up. If it is the rdns, it’s a new 
problem.


Do the HELO and RDNS have to match to pass spam detection? I would have 
thought that a valid, matching SPF record and the fact that the IP 
actually has a PTR etc would be sufficient.


Shane

*From:*Postmaster [mailto:i...@mailvue.com]
*Sent:* Friday, 24 November 2017 2:23 PM
*To:* Shane Clay <sh...@caznet.com.au>
*Subject:* Re: [mailop] Office 365 - Emails marked as not passing fraud 
detection


Could it be the rdns?

PTR:ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au 
<http://stcolumba.customer-wan.caznet.com.au>;




On Nov 23, 2017, at 8:31 PM, Shane Clay via mailop
<mailop@mailop.org <mailto:mailop@mailop.org>> wrote:

PTR:ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au
<http://stcolumba.customer-wan.caznet.com.au/>;



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop





--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic

A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Office 365 - Emails marked as not passing fraud detection

2017-11-24 Thread David Hofstee 
Maybe this... https://twitter.com/certbund/status/933674851092566017


David

On 24 November 2017 at 04:31, Shane Clay via mailop 
wrote:

> Hi All
>
>
>
> I can’t figure this one out so looking for some help from people in the
> know. One of our clients has a postfix mail relay server used for relaying
> emails from photocopiers/internal software systems out to the world.
>
>
>
> Below I’ve pasted the headers of one. Office 365 / Outlook chucks them in
> the junk mail folder with a message “This sender failed our fraud detection
> checks and may not be who they appear to be.”
>
>
>
> From what I can see, the email is matches SPF and is passing SPF/DMARC
> checks. I can’t understand what it is seeing as wrong.
>
>
>
> Any ideas?
>
>
>
> Shane
>
>
>
>
>
>
>
>
>
>
>
> Received: from SYXPR01MB1151.ausprd01.prod.outlook.com (10.171.35.141) by
>
> SY3PR01MB1145.ausprd01.prod.outlook.com (10.171.0.11) with Microsoft SMTP
>
> Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256)
> id
>
> 15.20.239.5 via Mailbox Transport; Fri, 24 Nov 2017 03:23:28 +
>
> Received: from ME1PR01CA0132.ausprd01.prod.outlook.com (10.171.9.145) by
>
> SYXPR01MB1151.ausprd01.prod.outlook.com (10.171.35.141) with Microsoft
> SMTP
>
> Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256)
> id
>
> 15.20.260.4; Fri, 24 Nov 2017 03:23:27 +
>
> Received: from ME1AUS01FT014.eop-AUS01.prod.protection.outlook.com
>
> (2a01:111:f400:7eb4::204) by ME1PR01CA0132.outlook.office365.com
>
> (2603:10c6:200:1b::17) with Microsoft SMTP Server (version=TLS1_2,
>
> cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.260.4 via Frontend
>
> Transport; Fri, 24 Nov 2017 03:23:27 +
>
> Received: from mail.stcolumba.sa.edu.au (103.219.120.34) by
>
> ME1AUS01FT014.mail.protection.outlook.com (10.152.232.114) with Microsoft
>
> SMTP Server id 15.20.178.5 via Frontend Transport; Fri, 24 Nov 2017
> 03:23:26
>
> +
>
> Received: from KM269386 (unknown [10.102.10.54])
>
> by mail.stcolumba.sa.edu.au (Postfix) with ESMTP id
> 95A4BC0BAE24
>
> for ; Fri, 24 Nov
> 2017 13:53:14 +1030 (ACDT)
>
> From: Simon Flaherty 
>
> To: Simon Flaherty 
>
> Subject:
>
> Thread-Index: AQHTZNOYCcOVafuWzkOoKK7iRk6SuQ==
>
> Date: Fri, 24 Nov 2017 03:32:02 +
>
> Message-ID: <20171124140202000ab70f.simon.flahe...@stcolumba.sa.edu.au>
>
> Content-Language: en-AU
>
> X-MS-Exchange-Organization-AuthSource: ME1AUS01FT014.eop-AUS01.prod.
> protection.outlook.com
>
> X-MS-Has-Attach: yes
>
> X-MS-Exchange-Organization-Network-Message-Id: 7b477dc8-ad88-4e86-092d-
> 08d532eab9f3
>
> X-MS-TNEF-Correlator:
>
> *received-spf: Pass (protection.outlook.com
> : domain of stcolumba.sa.edu.au
> *
>
> *designates 103.219.120.34 as permitted sender)*
>
> *receiver=protection.outlook.com ;
> client-ip=103.219.120.34;*
>
> *helo=mail.stcolumba.sa.edu.au ;*
>
> x-ms-publictraffictype: Email
>
> authentication-results: spf=pass (sender IP is 103.219.120.34)
>
> smtp.mailfrom=stcolumba.sa.edu.au; stcolumba.sa.edu.au; dkim=none (message
>
> not signed) header.d=none;stcolumba.sa.edu.au; *dmarc=pass* action=none
>
> header.from=stcolumba.sa.edu.au;compauth=pass reason=100
>
> x-microsoft-exchange-diagnostics: 1;SYXPR01MB1151;7:
> DnxrWG6h0x38Y2EwYd7DEFPIAttOlbuTEZYmD/+ZbnoP0Fl74xE8fI/
> MVEs1qvQPqsa2Gvgs6tN2+Gc0i1fgde8YkGz0CLD+BAXOUzvG4VzNhuJXVPMKQMR9PyXZ4V
> KaCv+PjtDvevqdEb+5BmGQK1fDvhcktBv0nzYWNxT+LoIAP/
> 4KQejWFVfF13wo9rRSzHjK6U9nqcx6+98hdB6lUv33MRcZFfaTxUDk56lukHj
> h6kFqcnM6vd2W6bCpINFnqR2QsI7KnIvm9am8YJ2X6g67gbITzvKHyyC2x/fRZ8s=
>
> x-forefront-antispam-report: CIP:103.219.120.34;IPV:NLI;
> CTRY:;EFV:NLI;SFV:SPM;SFS:(6009001)(8046002)(298032)(
> 438002)(189002)(199003)(2876002)(25636003)(305945005)(
> 567704001)(620011)(84326002)(5406001)(2171002)(
> 6266002)(589011)(81156014)(81166006)(74482002)(2351001)(
> 86152003)(14003)(42882006)(6916009)(101346004)(2148043)(003)(
> 566031)(5416004)(1076002)(63106013)(106002)(77096006)(
> 50986999)(500011)(568964002)(106466001)(54356999)(564344004)(
> 104016004)(356003)(37006003)(512874002)(2476003)(1096003)(
> 287071)(88552002)(86362001)(462011)(189998001)(429038);DIR:
> INB;SFP:;SCL:5;SRVR:SYXPR01MB1151;H:mail.stcolumba.sa.edu.au;FPR:;SPF:
> Pass;PTR:ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au
> ;MX:1;A:1;CAT:SPM;LANG:en;SFTY:9.11;
>
> x-ms-office365-filtering-correlation-id: 7b477dc8-ad88-4e86-092d-
> 08d532eab9f3
>
> x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(4534020)(49563074)(
> 121220049038)(71702078);SRVR:SYXPR01MB1151;
>
> x-ms-traffictypediagnostic: SYXPR01MB1151:
>
> x-ms-exchange-transport-endtoendlatency: 00:00:02.2240358
>
>

Re: [mailop] Office 365 - Emails marked as not passing fraud detection

2017-11-24 Thread Vladimir Dubrovin via mailop 

I would also suspect RDNS. The problem here is
ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au looks like
dynamic address and does not resolve back to IP:

$ host 103.219.120.34
34.120.219.103.in-addr.arpa domain name pointer
ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au.
$ host ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au
Host ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au not found:
3(NXDOMAIN)

So FCRDNS check fails.
https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS
And your assumption you have passed reverse DNS check is wrong.


24.11.2017 6:59, Shane Clay via mailop пишет:
>
> I’d considered that.
>
>  
>
> This server has been around a long time (and the rdns hasn’t changed)
> and the problem has only just come up. If it is the rdns, it’s a new
> problem.
>
>  
>
> Do the HELO and RDNS have to match to pass spam detection? I would
> have thought that a valid, matching SPF record and the fact that the
> IP actually has a PTR etc would be sufficient.
>
>  
>
> Shane
>
>  
>
> *From:*Postmaster [mailto:i...@mailvue.com]
> *Sent:* Friday, 24 November 2017 2:23 PM
> *To:* Shane Clay <sh...@caznet.com.au>
> *Subject:* Re: [mailop] Office 365 - Emails marked as not passing
> fraud detection
>
>  
>
> Could it be the rdns?
>
> PTR:ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au
> <http://stcolumba.customer-wan.caznet.com.au>;
>
>  
>
>
>
> On Nov 23, 2017, at 8:31 PM, Shane Clay via mailop
> <mailop@mailop.org <mailto:mailop@mailop.org>> wrote:
>
>  
>
> PTR:ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au
> <http://stcolumba.customer-wan.caznet.com.au/>;
>
>  
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


-- 
Vladimir Dubrovin
@Mail.Ru

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Office 365 - Emails marked as not passing fraud detection

2017-11-23 Thread Mark Milhollan 
On Fri, 24 Nov 2017, Shane Clay wrote:

>I can't figure this one out so looking for some help from people in the 
>know. One of our clients has a postfix mail relay server used for 
>relaying emails from photocopiers/internal software systems out to the 
>world.

>Any ideas?

I don't know, but can't an admin put the fixed IP address(es) in some 
sort of "known relay / good(ish)" list.  Of course if they have dynamic 
addresses that shoots that idea in the other foot.

For other receivers the SPF+DKIM should do the trick but those sorts of 
messages are faked by malware a lot.  Maybe be sure they aren't using a 
generic FROM.


/mark

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Office 365 - Emails marked as not passing fraud detection

2017-11-23 Thread Shane Clay via mailop 
Bill - the email wasn't aimed at asking Microsoft for support on a public 
mailing list. It wasn't a technical support request at all. It was from a 
network person, separate the end user, looking into an issue which he is 
unforunately lumped with, who decided to ask a community of people who 
specialise in e-mail if they possibly see something that he didn't amongst a 
set of email headers. Surely that is an appropriate discussion to have amongst 
professionals.

Anyway

To the couple of people who did reply off-list, thanks. I think I'm now armed 
with some useful information to send back to the client on what they should be 
doing to resolve it.

Shane



-Original Message-
From: mailop [mailto:mailop-boun...@mailop.org] On Behalf Of Bill Cole
Sent: Friday, 24 November 2017 2:44 PM
To: Shane Clay via mailop <mailop@mailop.org>
Subject: Re: [mailop] Office 365 - Emails marked as not passing fraud detection

On 23 Nov 2017, at 22:31 (-0500), Shane Clay via mailop wrote:

> Any ideas?

Maybe an organization that is clearly paying Microsoft for email services 
should consider the possible utility of going directly to Microsoft for 
support???

I'm 100% serious about that. It's been a few months since I was an admin for an 
O365 account, but in that time I strongly doubt that MS has become more opaque 
and unhelpful to their direct customers than they are to random non-customers 
on a public-ish mailing list. Michael Wise (of
MS) is frequently quite helpful here but only to a point that can often be 
vague because he needs to be vague. OTOH, using the available tools and support 
system inside O365 to make special exceptions for messages that look possibly 
fake (like ones too and from the same address) worked for me in seconds to days 
every time in the 4 years that I had to fix a FP problem there.

TL;DR: Those paying for a service should seek and receive support for that 
service from their paid service provider and in my direct experience, O365 
customers get that.

(You can't imagine how painful it is for me to praise MS.)

--
Bill Cole
b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many 
*@billmail.scconsult.com addresses) Currently Seeking Steady Work: 
https://linkedin.com/in/billcole

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Office 365 - Emails marked as not passing fraud detection

2017-11-23 Thread Bill Cole 

On 23 Nov 2017, at 22:31 (-0500), Shane Clay via mailop wrote:


Any ideas?


Maybe an organization that is clearly paying Microsoft for email 
services should consider the possible utility of going directly to 
Microsoft for support???


I'm 100% serious about that. It's been a few months since I was an admin 
for an O365 account, but in that time I strongly doubt that MS has 
become more opaque and unhelpful to their direct customers than they are 
to random non-customers on a public-ish mailing list. Michael Wise (of 
MS) is frequently quite helpful here but only to a point that can often 
be vague because he needs to be vague. OTOH, using the available tools 
and support system inside O365 to make special exceptions for messages 
that look possibly fake (like ones too and from the same address) worked 
for me in seconds to days every time in the 4 years that I had to fix a 
FP problem there.


TL;DR: Those paying for a service should seek and receive support for 
that service from their paid service provider and in my direct 
experience, O365 customers get that.


(You can't imagine how painful it is for me to praise MS.)

--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Currently Seeking Steady Work: https://linkedin.com/in/billcole

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Office 365 - Emails marked as not passing fraud detection

2017-11-23 Thread Shane Clay via mailop 
I'd considered that.

This server has been around a long time (and the rdns hasn't changed) and the 
problem has only just come up. If it is the rdns, it's a new problem.

Do the HELO and RDNS have to match to pass spam detection? I would have thought 
that a valid, matching SPF record and the fact that the IP actually has a PTR 
etc would be sufficient.

Shane

From: Postmaster [mailto:i...@mailvue.com]
Sent: Friday, 24 November 2017 2:23 PM
To: Shane Clay <sh...@caznet.com.au>
Subject: Re: [mailop] Office 365 - Emails marked as not passing fraud detection

Could it be the rdns?
PTR:ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au<http://stcolumba.customer-wan.caznet.com.au>;



On Nov 23, 2017, at 8:31 PM, Shane Clay via mailop 
<mailop@mailop.org<mailto:mailop@mailop.org>> wrote:

PTR:ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au<http://stcolumba.customer-wan.caznet.com.au/>;

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Office 365 - Emails marked as not passing fraud detection

2017-11-23 Thread Shane Clay via mailop 
Hi All

I can't figure this one out so looking for some help from people in the know. 
One of our clients has a postfix mail relay server used for relaying emails 
from photocopiers/internal software systems out to the world.

Below I've pasted the headers of one. Office 365 / Outlook chucks them in the 
junk mail folder with a message "This sender failed our fraud detection checks 
and may not be who they appear to be."

>From what I can see, the email is matches SPF and is passing SPF/DMARC checks. 
>I can't understand what it is seeing as wrong.

Any ideas?

Shane





Received: from SYXPR01MB1151.ausprd01.prod.outlook.com (10.171.35.141) by
SY3PR01MB1145.ausprd01.prod.outlook.com (10.171.0.11) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id
15.20.239.5 via Mailbox Transport; Fri, 24 Nov 2017 03:23:28 +
Received: from ME1PR01CA0132.ausprd01.prod.outlook.com (10.171.9.145) by
SYXPR01MB1151.ausprd01.prod.outlook.com (10.171.35.141) with Microsoft SMTP
Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id
15.20.260.4; Fri, 24 Nov 2017 03:23:27 +
Received: from ME1AUS01FT014.eop-AUS01.prod.protection.outlook.com
(2a01:111:f400:7eb4::204) by ME1PR01CA0132.outlook.office365.com
(2603:10c6:200:1b::17) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.260.4 via Frontend
Transport; Fri, 24 Nov 2017 03:23:27 +
Received: from mail.stcolumba.sa.edu.au (103.219.120.34) by
ME1AUS01FT014.mail.protection.outlook.com (10.152.232.114) with Microsoft
SMTP Server id 15.20.178.5 via Frontend Transport; Fri, 24 Nov 2017 03:23:26
+
Received: from KM269386 (unknown [10.102.10.54])
by mail.stcolumba.sa.edu.au (Postfix) with ESMTP id 95A4BC0BAE24
for ; Fri, 24 Nov 2017 
13:53:14 +1030 (ACDT)
From: Simon Flaherty 
To: Simon Flaherty 
Subject:
Thread-Index: AQHTZNOYCcOVafuWzkOoKK7iRk6SuQ==
Date: Fri, 24 Nov 2017 03:32:02 +
Message-ID: <20171124140202000ab70f.simon.flahe...@stcolumba.sa.edu.au>
Content-Language: en-AU
X-MS-Exchange-Organization-AuthSource: 
ME1AUS01FT014.eop-AUS01.prod.protection.outlook.com
X-MS-Has-Attach: yes
X-MS-Exchange-Organization-Network-Message-Id: 
7b477dc8-ad88-4e86-092d-08d532eab9f3
X-MS-TNEF-Correlator:
received-spf: Pass (protection.outlook.com: domain of stcolumba.sa.edu.au
designates 103.219.120.34 as permitted sender)
receiver=protection.outlook.com; client-ip=103.219.120.34;
helo=mail.stcolumba.sa.edu.au;
x-ms-publictraffictype: Email
authentication-results: spf=pass (sender IP is 103.219.120.34)
smtp.mailfrom=stcolumba.sa.edu.au; stcolumba.sa.edu.au; dkim=none (message
not signed) header.d=none;stcolumba.sa.edu.au; dmarc=pass action=none
header.from=stcolumba.sa.edu.au;compauth=pass reason=100
x-microsoft-exchange-diagnostics: 
1;SYXPR01MB1151;7:DnxrWG6h0x38Y2EwYd7DEFPIAttOlbuTEZYmD/+ZbnoP0Fl74xE8fI/MVEs1qvQPqsa2Gvgs6tN2+Gc0i1fgde8YkGz0CLD+BAXOUzvG4VzNhuJXVPMKQMR9PyXZ4VKaCv+PjtDvevqdEb+5BmGQK1fDvhcktBv0nzYWNxT+LoIAP/4KQejWFVfF13wo9rRSzHjK6U9nqcx6+98hdB6lUv33MRcZFfaTxUDk56lukHjh6kFqcnM6vd2W6bCpINFnqR2QsI7KnIvm9am8YJ2X6g67gbITzvKHyyC2x/fRZ8s=
x-forefront-antispam-report: 
CIP:103.219.120.34;IPV:NLI;CTRY:;EFV:NLI;SFV:SPM;SFS:(6009001)(8046002)(298032)(438002)(189002)(199003)(2876002)(25636003)(305945005)(567704001)(620011)(84326002)(5406001)(2171002)(6266002)(589011)(81156014)(81166006)(74482002)(2351001)(86152003)(14003)(42882006)(6916009)(101346004)(2148043)(003)(566031)(5416004)(1076002)(63106013)(106002)(77096006)(50986999)(500011)(568964002)(106466001)(54356999)(564344004)(104016004)(356003)(37006003)(512874002)(2476003)(1096003)(287071)(88552002)(86362001)(462011)(189998001)(429038);DIR:INB;SFP:;SCL:5;SRVR:SYXPR01MB1151;H:mail.stcolumba.sa.edu.au;FPR:;SPF:Pass;PTR:ip-103-219-120-34.stcolumba.customer-wan.caznet.com.au;MX:1;A:1;CAT:SPM;LANG:en;SFTY:9.11;
x-ms-office365-filtering-correlation-id: 7b477dc8-ad88-4e86-092d-08d532eab9f3
x-microsoft-antispam: 
UriScan:;BCL:0;PCL:0;RULEID:(4534020)(49563074)(121220049038)(71702078);SRVR:SYXPR01MB1151;
x-ms-traffictypediagnostic: SYXPR01MB1151:
x-ms-exchange-transport-endtoendlatency: 00:00:02.2240358
x-ms-exchange-crosstenant-originalarrivaltime: 24 Nov 2017 03:23:26.0304 (UTC)
x-ms-exchange-crosstenant-fromentityheader: Internet
x-ms-exchange-crosstenant-id: fba15b65-df58-4536-b68c-9abdfb1b006d
x-ms-exchange-transport-crosstenantheadersstamped: SYXPR01MB1151
x-ms-exchange-crosstenant-network-message-id: 
7b477dc8-ad88-4e86-092d-08d532eab9f3
X-Microsoft-Exchange-Diagnostics: 
1;SY3PR01MB1145;27:70Llm1qlaswKeTTjCRyGryotp55ZC6CdTXHVoVvU2XJn8cdH4tsLWhaczNNmkLluWk/awzKlBGwt1ze1f8Qk9Eif/AFCoj/xzB6lqbGpxIsm/vwNGq1hUSf62wr4jsC4
Content-Type: multipart/mixed;