We started having a problem recently where if there is a hosted mailbox such as [email protected] then that address (since it was the to) is getting added onto the ticket as a contact. This then causes a loop when a notification goes out and it gets sent back to that address.
We’ve had to adjust our rules to create specific exclusion rules which check that the to or cc address does not equal [email protected].
It didn’t seem to do this previously. I would think that the destination address would be explicitly excluded from the email address array.
As I’m writing this, I think I realized what the problem is. We don’t always send directly to the @mspiparser.com hosted address. We’re using an alias that belongs to the company and then it gets forwarded to the mspiparser address so that its hidden from that discussion.
so in this case we might have [email protected] → (forward) → [email protected].
While the example@ wouldn’t be added, the original [email protected] would be and that creates the loop.
So the actual question then would be - is there a way for the incoming processor to realize what the original email address that gets forwarded is and exclude that as well?
Hi @DBachen
Does this help?
One side-note: that page says that email.to.[0].address is the address your user typed. We will clarify the docs, but we don’t guarantee that the address is in slot 0. If the user sent to several people, any of the email.to address properties may be the one that forwarded to you (i.e. it may be email.to.[1].address or email.to.[27].address, etc).
yeah, that certainly helps at least identifying that the email.to.[0].address might be the forward (and usually is), but you can’t guarantee it… They might have sent it to one of their staff or vendor and then cc’d us.
Guess that means you can’t automatically exclude the [0] address because there is no guarantee it is the forward and you might exclude the wrong person.
I’m currently checking in the add all to and add all cc email loops that the custom.address.address <> [email protected]. Guess I’m going to have to stick with that since it can be in any position on either array.
There isn’t anything in the headers that let’s you tie those 2 things together.
Maybe something you could add to your “next version” that I know you’re working with? Give us a spot where we can save a property on the hosted mailbox besides just the mailbox prefix. Something like “Original forward address(es)”. That would be a way to signify what its being sent to and you could ignore that on purpose regardless of it’s position.
Thanks either way.
The general pattern we recommend is to hard-code the forwarded address(es) in your rule so that MSPintegrations never creates a contact for that (those) address(es). You could likely filter out the entire email domain for you organization.