Trying to find what is breaking on the parse
Automated alerts from blackpoint SOC
The email address to be parsed is in the email body, since the email is sent from a noreply email address
Can you provide the URL to an example email in your history or to the rule you’ve built? There’s a little context there that will be helpful in our answer.
For reference, here are the rules in the mailbox you creatd:
From your history, it looks like the issue starts when Step 1 is unable to extract the email address:
Here’s Step 1 expanded for reference:
I copied your regular expression and the body of your email to my favorite regex debugging site, regex101.com and confirmed there is no match for this pattern in the email (I redacted personal info for the screenshot). Notice the column on the right shows no match of the regex:
I made some changes to your regex and got it to work. Another screenshot of it now working (with the same redactions). Notice the right side shows “Group Email” with my redacted email address:
Here is your original regex pattern:
has detected that \*(?<email>[^*]*)\*
Here is my updated regex pattern:
has detected that (?<email>[\w\.\d@_]*)
Please update the regex in your rule to the new regex I created. I expect the rule will work correctly.
Also, I noticed that the failure of the match caused MSPintegrations to query Autotask for an empty query, which returned the maximum number of results:
You can fix that by editing Step 2 to add this expression:
Let us know how this works!
No changes, but this one Processed just fine
https://console.mspintegrations.com/#/email2at/advanced/history/169844389503476
However would like to pull in this info from the email to be part of the ticket title
has authenticated from a New Device and IP Address
The reason the second example you linked worked but the first example did not is they contain different email body text.
Here’s (part of) the body in the first example:
Blackpoint Cloud Response for Microsoft 365 has detected that
[email protected]<mailto:[email protected]> has created
a anonymous file share link for the file at the URL:
https://REDACTED-my.sharepoint.com/REDACTED
Here’s the latest example:
Blackpoint Cloud Response for Microsoft 365 has detected that
*[email protected]* has successfully authenticated to Microsoft
365 from a new device and IP address not previously seen. Unlike
sign-ins from unapproved countries, you will only receive one
notification for each unique device and IP address so there is no
need to contact Blackpoint to allow-list this activity.
The first example contains
has detected that [email protected]
And the second example contains:
has detected that *[email protected]*
Your original regex is looking for the * characters, but the first example doesn’t wrap the email in * characters.
The challenge here is that you will need to use different patterns when extracting text from emails that contain different text.
You might consider extracting from the subject line, instead. Both subject lines are the same format:
YOUR COMPANY - [email protected] has ________________
Would you like to extract the sender from the subject line? Do you need help building that expression?
Travis,
The issue is that we have seen from previous history before pushing into this platform that the email address does not always come in via the subject line
Example - This is a one time generated junk address due to 365 Intune account generation
Then run into something like this
Then run into these where the email address is in the body for a sharepoint site build
Also was wondering if we can make a decision point for example
If its just an alert that Azure did its job - Lockout, since we want to log the ticket, but no work to be done to built and auto close the ticket
Example item - Company - [email protected] has triggered Azure smart lockout
https://console.mspintegrations.com/#/email2at/advanced/history/169847514107847
In the case where the are a number of potential inbound email formats, you could use logic like this:
- Extract email address matching pattern #1
- If no extracted email address yet, extract email address matching pattern #2
- If no extracted email address yet, extract email address matching pattern #3
- If no extracted email address yet, extract email address matching pattern #4
- If no extracted email address yet, extract email address matching pattern #5
… - If an extracted email address matched, create a ticket for the contact and its account
- If no extracted email address matched, create a ticket on catch-all account
Using this sort of logic, you can start by building text matching steps to extract email addresses using the most common matching patterns. Then, as you later identify more formats of email, you can add more steps to extract email addresses of additional formats.
For sake of example, the first step may look like this:
And the second step like this:
The Only perform this action if the following condition is met of the second step would look like this:
With this setup, step 1 will always fire and extract the email address between has detected that and <mailto:.
Step 2 will fire if nothing was extracted in step 1, and step 2 will look for the email address between has detected that * and *has successfully.
You could then add step 3 to look for the email address a different way, and step 4 for yet another way, etc.
With this setup, the system would try to extract the email address a few ways until it found the address, and then it would not try any other ways.
Over time, you can add more steps to extract it in different ways as you identify emails that come through without a match.
How do you think that will work for you?