Im triggering a Phishing workflow with a new message to an Inbox,
We want to make sure to cover not only forwarded emails but also emails attached as EML in the reports.
I’m currently using Gmail Plugin 6.0.1, I got the workflow triggered by new message but cannot seem to see any relevant information from the EML attached.
Trigger > EMLattachedLoop > HeaderLoop > ExtractIt(domains) = update.eml
Although the EML i’m passing, have way more information.
Are you checking the attached email objects as well? They’ll come through as either “attached email” or “flattened attached emails” depending on how you setup your trigger. (There’s a flatten attachments option…which I’d almost always have turned on).
thanks for your response.
I have indeed set up the trigger to have “flattened attached emails” as array output.
Then afterwards I use a Loop to go through the array, and then inside another loop inside to go through the headers and extract domains…
The iterations come by, but the output still is
Are you looping on the attachments here or the base email? The email headers refers to the email itself not it’s attachments.
I’m looping on the attachments, then I loop inside on the variable step.$item.headers.
Here check this out:
That workflow does what you’re trying to do.
However, you might have an email that’s not parsing correctly, it’s rare these days, but we run into it now and again. Email is an extremely complicated protocol.
Check out that workflow and see if it helps. If it doesn’t let me know, and I’ll look at your email to see if something weird is going on.
I well check and post it here!
Hey joey, just imported the example workflow, but still the same output.
Email me the email - firstname.lastname@example.org - I’ll look at it on my end and see what’s going on. Give me some time as it’ll take a bit to analyze what’s going on.
Ok, I pulled this email down, and it’s a bug with how we parse emails (sort of). The email you sent, when I look at just the text, is missing a section (emails come in parts that have parts in them). Usually that’s not a big deal, and our email parser skips over it and finds that information in other places, but for some reason, here it’s trying to return that blank piece.
That’s why you’re not getting the indicators you’re expecting out of this.
Sooo…TL;DR…we’ve got a bug, I’ll put in a ticket, and we’ll try to get a fix out soon. A very very rough ETA is next week-ish. (It depends on how testing goes…email is complicated, and if in changing this, we break something else in the email, these fixes can take a while).
Sorry for the inconvenience, and thanks for bringing this to our attention. We’ll get this out as soon as we can.
Thanks for the update, we know how difficult is to retrieve data out from headers as each provider can place headers at their will ( with certain boundaries ofc ).