Enable Report Message Add-In For Office 365

Posted on Leave a commentPosted in add-in, EOP, exchange online, Exchange Online Protection, Office, Office 365, Office 365 ProPlus, phish, phishing, spam

There is a new add-in available for Outlook and OWA in Office 365 that can simplify spam and phishing reporting to Microsoft for content in your mailbox. I recommend rolling this add-in out to everyone in your Office 365 tenant and for Office 365 consultants to add this as part of the default steps in deploying a new tenant.

This can be done with the following steps:

In the Exchange Control Panel at https://outlook.office365.com/ecp/ go to the Organization > Add-Ins section

image

Click the + icon and choose “Add From Office Store”.

In the new tab that appears, search for “Report Message” via the search bar top right:

I’ve noticed that a set of search results appear, then the website notices I am logged in, logs me in and presents a second smaller list of results. It is in this small list that you should see Report Message by Microsoft Corporation

image

I’ve noticed that clicking “Get it now” does not seem to work all the time (the popup has a Continue button that does nothing)! So if that happens, cancel the popup, click the card for the app and install the add from the Get it now button rather than the get it now link on the card. The Report Message app page is shown below with a “Get It Now” button to the left:

image

Either the link or the button should work, and you should get this popup:

image

Click Continue. You are taken to Office 365 to continue. This is the step I eluded to above that sometimes does not work

image

You are asked to confirm the installation of the App into Office 365

image

Click Yes and wait a while. I’ve noticed also that sometimes you need to refresh this page manually for the process to continue, though waiting (with no indication that anything is happening for one or two minutes is usually enough as well)

image

The message above says that the add-in is now visible in the gray bar above your messages. For this add-in this is not correct as this add-in extends the menu in Outlook (2013 and later, as add-ins are not supported in Outlook 2010) and also the app is disabled by default.

Close this tab in your browser and return to the add-in page in Exchange Control Panel that is open in a previous tab.

Refresh the list of apps to see the new app:

image

From here you can enable the app, select a pilot audience, though this app is quite silent in the users view of Outlook and OWA so a pilot is not needed for determining impact to users, but can be useful for putting together quick documentation or informing the help desk of changes.

Select the app and click the edit button:

image

I recommend choosing “Mandatory, always enabled. Users can’t disable this add-in” and deploying to all users. Unchecking the option to make it available for all users makes it available for none. For a pilot choose “Optional, disabled by default”.

You are now done installing the add-in.

Users will now see the add-in in Outlook near the Store icon when a message is selected open:

image

Clicking the icon allows you to mark a messages as “junk”, “phishing” or “not junk” and options and help. Options gives the following:

image

Where the default is to ask before sending info to Microsoft.

Selecting Junk or Phishing will result in the message being moved to Junk Email folder in Outlook, and if in the Junk Email folder, marking a message “Not Junk” will return it to the inbox. All options will send info on the message, headers and other criteria to Microsoft to help adjust their machine learning algoriths for spam and phishing detection. This add-in replaces the need to email the message as an attachment to Microsoft.

For a pilot, users need to add the add-in themselves to Outlook. Mandatory deployment means it is rolled out to users (usually within a few days). To enable the add-in in OWA, click the options cog to the top right of the OWA interface:

image

Then click Manage Add-Ins and scroll down until you find the Report Message add-in (or search for it)

image

And turn the add-in on to view it in OWA as shown:

image

And also it will appear automatically in Outlook for iOS and Outlook for Android and Outlook (desktop, classic).

Once the app is enabled for all users, and recall the above where it takes a while to appear for all users, then your spam and phish reporting in Office 365 is very simple and easy to do and easy to remove from a helpdesk call and on to the end user directly to report and move messages.

Get-SpoofMailReport in EOP

Posted on Leave a commentPosted in EOP, exchange online, Exchange Online Protection, Office 365, spam, spoof

Using Office 365 or EOP to protect your email and worried about spoofed emails? Then try this cmdlet in Remote PowerShell for EOP:

PS C:\Users\brian.reid> Get-SpoofMailReport

Date                Event Type Direction Domain Action       Spoofed Sender              True Sender     Sender IP
—-                ———- ——— —— ——       ————–              ———–     ———
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         mandrillapp.com 198.2.186.0/24
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         someapp.com     198.2.179.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com             mimecast.com    1.130.217…
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                       1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                       1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                       1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          1.130.217…
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com             mimecast.com    91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com                             1.130.217…
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com                             91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com             mimecast.com    91.220.42.0/24
10/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                          1.130.217…
11/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                          1.130.217…
11/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk                      1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     paul@domain.com                             91.220.42.0/24
07/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         mandrillapp.com 198.2.132.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     andrew@domain.com           mimecast.com    91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com          mimecast.com    91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          91.220.42.0/24
08/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.co.uk     mimecast.com    1.130.217…
10/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
10/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com                         1.130.217…
11/04/2016 00:00:00 SpoofMail  Inbound          CaughtAsSpam wordpress@other.com         host-h.net      129.232.144…
11/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com         host-h.net      197.189.237…
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
13/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com                         91.220.42.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     no-reply@domain.com         mandrillapp.com 198.2.187.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.co.uk                     1.130.217…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com         host-h.net      197.189.237…
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@other.com                         91.220.42.0/24
14/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.co.uk     mimecast.com    1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com                          1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    1.130.217…
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     wordpress@domain.co.uk      mimecast.com    91.220.42.0/24
17/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     support@domain.com                          91.220.42.0/24
18/04/2016 00:00:00 SpoofMail  Inbound          GoodMail     postmaster@domain.com       mimecast.com    91.220.42.0/24

Thats the output I get from running this on the afternoon of April 20th (UK style dates for the American readers of this blog)! Notice a few things (its been somewhat redacted to remove private into), but the spam filter provider in front of EOP in this tenant is seen as spoofing postmaster emails and there are some from mandrillapp.com in a similar vein. Both of these companies send email on our behalf, so I expect to see them here – so nothing to see here for these. How about the others? One is a hosting company, probably hosting WordPress instances and so these are probably alerts of some kind from a web hoster to us, so again I think for us nothing here.

What do you get – is it more interesting for you?

Then finally, how about getting the results in date order, as they are not by default: Get-SpoofMailReport | sort -Property Date

 

 

Is Your SenderID/SPF or DKIM Record Correctly Configured

Posted on Leave a commentPosted in DNS, domain, exchange, exchange online, IAmMEC, MX, Office 365, spam

With Microsoft having just announced that DKIM is coming to Office 365 soon (release notes here) and SenderID is already available, I thought this is a good time to write a blog on the use of DMARC to show if your records are correct.

DMARC is a protocol that allows you to see the effect of your SenderID/SPF records from the viewpoint of the recipient – as long as the recipient is one of the larger email receivers in the world, but that should be enough to help you validate your SenderID/SPF records. DMARC is currently in use at Outlook.com/Hotmail, Gmail, Facebook, Yahoo and Twitter to name some of the larger users of it.

To receive the results of a DMARC report you need to add your DMARC policy as a new TXT record to DNS. It looks something like this:

_dmarc IN TXT “v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com”

This TXT record for “_dmarc” at the root of your domain tells the receiver to report back to you all (pct=100) SenderID/SPF failures. They also report DKIM failures as well. If you send lots of email you might want to report on a smaller number of overall failures, say pct=20! The record says who to send the report to (rua=email address).

Finally, and one of the most useful bits of DMARC is that you can tell the receiver what to do with failures in your SenderID/SFP or DKIM record. For example in SenderID/SPF you can set the modifier “-all” to the end. This says that anything not covered in the rest of the record is to fail SenderID. The recipient then decides what to do with your email (as it might be your email, as you might have got your SPF or DKIM record wrong). In the example above you tell the recipient email system you would like them to reject (p=) the email. The policy could be quarantine or none. The policy p=none means accept the message, but report it back to the rua email address in the DMARC record.

p=none allows you to introduce SPF/DKIM and ensure no rejection of your messages at the recipient end, but get reporting back on the IP addresses from which your emails (or spoofed emails) are coming from.

Once you are sure your SPF/DKIM records are correct change your policy to p=quarantine and then when you are finally sure, change it to p=reject.

An example of creating a DMARC policy on your domain is shown below. The below example is AWS Route 53 DNS, but any DNS management console that support TXT records should work:

image

Finally, as this is just a quick intro to DMARC, you can use the ruf= qualifier to set the email address of per message failure reports.

Cannot Send Emails To Office 365 or Exchange Online Protection Using TLS

Posted on 10 CommentsPosted in 2003, 2007, 2010, 2013, exchange, exchange online, Exchange Online Protection, FOPE, hybrid, Office 365, spam, starttls, TLS

I have found this is a common issue. You set up an Exchange Online Hybrid or Exchange Online Protection (EOP) stand alone service and follow all the instructions for the creating of the connectors needed, only to find that your emails queue in your Exchange Server. If you turn on protocol logging you get this error in the log “Connector is configured to send mail only over TLS connections and remote doesn’t support TLS” and if you look at the SMTP protocol verbs that are recorded in the log you see that Microsoft’s servers do not offer STARTTLS as a verb.

STARTTLS is the SMTP verb needed to begin a secure and encrypted session using TLS. Communication between your on-premises servers and Microsoft for hybrid or EOP configurations requires TLS and if you cannot start TLS then your email will queue.

If you are not configuring hybrid or EOP standalone and need to send an email to someone on Office 365 then this is not an issue, because Exchange Server does not require TLS for normal email communication and so the lack of a STARTTLS verb means your email is sent in clear text.

The reason why you are not getting STARTTLS offered is that your connecting IP address is on the Microsoft block list. If you change your connector (temporarily) to allow opportunistic TLS or no TLS at all then your emails will leave the queue – but will be rejected by the Microsoft servers. The NDR for the rejection will tell you to email Microsoft’s delisting service. So now you have an NDR with the answer to the problem in, you can fix it! It takes 1 to 2 hours to get delisted from when Microsoft process your email – so they say it takes 48 hours end to end.

Therefore my recommendation when setting up Exchange Online Hybrid or stand alone EOP is to send an email over plain text to EOP before you configure your service. If you are on the blocklist then you will get back the delisting email and you can process that whilst setting up the connectors to Office 365 and so by the time you are ready to test, you are off the blocklist!

To send a test email over Telnet

  1. Install the Telnet Client feature on your Exchange Server that will be your source server for hybrid or connectivity to EOP for outbound email
  2. Type the following. This will send an email to a fake address at Microsoft, but will hit the TLS error before the message is rejected

    telnet microsoft-com.mail.protection.outlook.com 25

  3. You are now connected to Exchange Online Protection and you should get a 220 response
  4. Type the following to send the email by command line. No typo’s allowed in telnet, so type carefully. Replacing your email address where prompted so that you get the NDR back to you.

    ehlo yourdomainname.com
    mail from: youremailaddress@domainname.com
    rcpt to: madeupaddress@microsoft.com
    data
    from: Your Name <youremailaddress@domainname.com>
    to: madeupaddress@microsoft.com
    subject: testing to see if my IP is blocked

    type something here, it does not matter what, this is the body of the message you are sending
    .

  5. A few points about the above. It must finish with a . (full stop) on a line by itself followed by a carriage return. There must be a blank line between the subject line and the body. And finally, for each line of data you type, the Microsoft SMTP servers will return either a 250 or 354 response.

Moving Exchange Online Protection Junk Mail to the Junk Email Folder

Posted on Leave a commentPosted in 2007, 2010, 2013, active directory, cloud, Edge, EOP, exchange, exchange online, FOPE, mcm, mcsm, spam, transport

If you use Exchange Online Protection (EOP) to filter your email in the cloud and to remove spam and malware before onward delivery to you, and if you use Exchange 2007 or later on-premises, then you need to configure Exchange to move detected spam to the Junk Email folder in Outlook.

By default EOP detects two levels of spam (malware is automatically removed) and tags them. In Exchange, you need to use Transport Rules to move these emails to the users Junk Email folder. If you wish for EOP throw away junk emails of either detection level (i.e. high junk is discarded) then you still need to configure these transport rules to move the remaining detected junk email into the Junk Email folder in Outlook. If you place all EOP detected spam in the quarantine or throw it away, you should still create these transport rules as it means they are in place for any future changes you make at EOP.

If you use Exchange Online (part of Office 365) then you do not need to create these rules as they already exist (though you cannot see them in any admin tools you have).

The Transport Rules To Create

The following four transport rules need to be created on your Exchange organization. These four rules get created with the highest priority, moving all existing rules below them. They set the Spam Confidence Level of the message to 6 in these examples, though this should be set to a value that exceeds the SCLJunkThreshold organization wide setting for your Exchange Organization, as any email that exceeds this value is placed into the Junk Email folder upon delivery to the users mailbox.

New-TransportRule "Move EOP Detected Spam (SFV:SPM) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SPM" -SetSCL 6 -Priority 0

New-TransportRule "Move EOP Detected Spam (SFV:SKS) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SKS" -SetSCL 6 -Priority 1

New-TransportRule "Move Personal Block List Spam (SFV:SKB) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SKB" -SetSCL 6 -Priority 2

New-TransportRule "Move Bulk Email (SFV:SKB) to Junk Email Folder" -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SRV:BULK" -SetSCL 6 -Priority 2

Once these two rules are run, AD replication will need to be allowed to happen and then all Exchange Servers will action this rule for any email that EOP thinks is spam. The default value for SCLJunkThreshold is 4, so as long as the rules set the SCL value to greater than this value it should work. Use Get-OrganizationConfig | FL SCLJunkThreshold to get this value for your organization.

What the EOP Message Tags Mean

The X-Forefront-Antispam-Report header in the email contains many values. See http://technet.microsoft.com/en-us/library/dn205071(v=exchg.150).aspx for what EOP thinks about the spam rating of the message.

  • SFV – means Spam Filtering Verdict
  • SFV:SFE – Originated from a Safe Sender (EOP learns Outlook safe senders due to Windows Azure Directory Sync)
  • SFV:BLK – Originated from a Blocked Sender
  • SFV:SPM – Spam
  • SFV:SKB – Emails where the sender is on the users personal block list as configured in OWA or Outlook Junk Email settings
  • SFV:SKS – (SKIP) The message was marked as spam prior to being processed by the spam filter. This includes messages where the message matched a Transport rule to automatically mark it as spam and bypass all additional filtering
  • SFV:NSPM – Not Spam

Article updated in June 2016 to include new headers and go from two rules to four