Al Douglas
My feedback
-
95 votesfeedback taken · 7 comments · Office 365 Security & Compliance » Spam & Phishing · Flag idea as inappropriate… · Admin →
Al Douglas supported this idea ·
-
3,743 votes110 comments · Office 365 Security & Compliance » Spam & Phishing · Flag idea as inappropriate… · Admin →
This is work we are planning to do although there is no ETA at this time.
Al Douglas supported this idea ·
An error occurred while saving the comment -
329 votes
An error occurred while saving the comment Al Douglas commented
The ETR method still appears to have the desired outcome from my testing, but it should be noted that the header added by the transport rule is not preserved for security reasons, but adding the header via ETR still appears to have the desired effect of skipping attachment detonation / safe links rewrite. If this is found not to be the case, please log a call with support.
-
215 votes
Al Douglas supported this idea ·
-
221 votes
An error occurred while saving the comment Al Douglas commented
This should be completed.
https://docs.microsoft.com/en-us/office365/securitycompliance/set-up-atp-safe-links-policies
Do not rewrite the following URLs
Leaves URLs as they are. Keeps a custom list of safe URLs that don't need scanning for a specific group of email recipients in your organization. See Set up a custom "Do not rewrite" URLs list using ATP Safe Links for more details, including recent changes to support for wildcard asterisksAn error occurred while saving the comment Al Douglas commented
Hi all. Worth noting that Wildcards are now allowed (See https://support.office.com/en-us/article/Set-up-a-custom-do-not-rewrite-URLs-list-using-Office-365-ATP-safe-links-35dbfd99-da5a-422b-9b0e-c6caf3b645fa), and ETR's can also be used to prevent links from being re-written by the addition of a specific header (but only by the tenant administrator). Support can assist with these if required
-
9 votes
An error occurred while saving the comment Al Douglas commented
Hi Paul. There are still a number of factors which can have an adverse effect on DKIM signing, so for now the RFC guidance is that it is against RFC advice block or mark as spam due to a DKIM failure, https://tools.ietf.org/html/rfc6376 section 6.1
"Survivability of signatures after transit is not guaranteed, and signatures can fail to verify through no fault of the Signer. Therefore, a Verifier SHOULD NOT treat a message that has one or more bad signatures and no good signatures differently from a message with no signature at all."These are being looked into as DKIM developments occur, but recipient systems should heed RFC guidance due to the known limitations
Please see the following workaround for now https://blogs.msdn.microsoft.com/tzink/2018/05/21/a-way-to-sort-of-approximate-dmarc-aggregate-reports-in-office-365/