The Subscriber Resolver allows you to create a mapping between the data in incoming reports and your subscribers. There are different types of Subscriber Resolver that can be combined as needed using the Inbound Processing. The input of a subscriber resolver is the parsed data and the output is the desired subscriber id that is used in AbuseHQ to identify your subscriber.
It is also possible to stack more than one Subscriber Resolver behind another. An example could be, to use the E-Mail Address of the original Sender (From Header Resolver) and enrich the data with information of your Provisioning or CRM System by using an API Call (API Subscriber Resolver). When stacking Subscriber Resolvers we always update and therefore overwrite already existing information.
Following you will learn about the most commonly used subscriber resolvers.
The Incident IP Resolver is configured by default when a new AbuseHQ instance is created. It simply uses the IP that has been parsed from the report as the subscriber id. This works well for static IPs, but not for dynamic ones.
The API Resolver is the most powerful of all resolvers. You can send the event data to an HTTP endpoint you built and return a subscriber id. This gives you the freedom to query your own databases and other systems. If you assign IPs dynamically, for example, you can use the events IP and timestamp to find out in your systems which of your subscribers was assigned this IP at that time. You can also return more fields to enrich the subscriber with more data.
If one of your resolvers cannot resolve the subscriber, you can chain them together and use different mechanisms to resolve it. If, at the end of your inbound processing graph, the subscriber has still not been resolved, the event will be marked as unresolved. You can find unresolved events in the AbuseHQ Mailbox Frontend but no case will be created.
Updated 2 years ago