Inbound and tracking endpoints for Mandrill need two separate webhook keys

[jonathanbaugh]

Hello!

I'm working on switching our use of djrill over to anymail with Django 1.8 on python 2.7 (we're working on upgrading to 1.11 and djrill is one of the final packages to go). We handle a lot of inbound messages so, I'm very excited to see this feature coming along :-)

Our current Mandrill setup has a single webhook which handles both tracking and inbound with a single key. As far as I can tell there is no way to have the same key between two different webhooks.

The anymail setup for the feature_inbound branch adds a second URL specifically for inbound and either tracking or inbound views will raise the following exception:

AnymailConfigurationError: You seem to have set Mandrill's *inbound* webhook URL to Anymail's Mandrill *tracking* webhook URL.

So the problem is:

• If we create a second webhook we would have a second key generated resulting in a signature error on one of the endpoints.
• If we use a single endpoint we raise the configuration error.

I'm considering adding a third signal and set of endpoints that handle any event type. I'm happy to submit a pull request for that but before I do it I want to check: is there already another solution in mind?

Thanks!
Jonathan

[medmunds]

Thanks for reporting this. I'd been wondering how Mandrill handled this, as their docs aren't clear about keys for multiple webhooks (and MailChimp doesn't offer access to Mandrill for testing).

I can see three ways to solve this:

1. Switch to a single webhook url for Mandrill, used for both inbound and tracking, and dispatch the inbound or tracking signal based on the event payload. (There shouldn't be a need to introduce a third signal, and doing so would make using Mandrill different from the other ESPs, which is something Anymail tries hard to avoid.)
2. Split the MANDRILL_WEBHOOK_KEY setting into separate MANDRILL_INBOUND_WEBHOOK_KEY and MANDRILL_TRACKING_WEBHOOK_KEY settings.
3. Change MANDRILL_WEBHOOK_KEY to allow a list of keys (like WEBHOOK_AUTHORIZATION does), and validate against any of them.

I'm thinking that even with the first two, we'd also want to allow a list of webhook keys, to facilitate credential rotation. (Mandrill generates a new webhook key if you try to change the shared-secret auth part of the webhook url, right?)

Given that, I'd kind of lean toward just doing the third one. Thoughts?

Related question: Have you needed to use Anymail's MANDRILL_WEBHOOK_URL setting? (Were you using the DJRILL_WEBHOOK_URL setting?)

[jonathanbaugh]

Thanks for getting back to me (and for your work on these modules!)

I kind of like all of the proposed solutions. Because I'm a bit behind schedule I'll submit a PR tomorrow for a single URL for Mandrill. That should help people with a similar configuration (described below) over to anymail from djrill.

Between solution 2 and 3 I think I'd go with 2. It will be more performant as signatures only need to be calculated a single time regardless of success. A loop over multiple keys will have the wrong key much of the time depending on how many expired keys are in the list and the order they're in.

The configuration of solution 2 is also more clear. It you have both inbound and tracking webhooks in Mandrill and you need to change one of them it's going to be easier to review.

If solution 2 defaults back to MANDRILL_WEBHOOK_KEY when MANDRILL_INBOUND_WEBHOOK_KEY or MANDRILL_TRACKING_WEBHOOK_KEY aren't present then it means you can more clearly maintain configurations where a single webhook is being used.

Solution 3 has the benefit of being more intuitive and less verbose. I looked into the documentation and codebase to see if it was supported while debugging. If other ESPs support multiple keys for rotation it makes a lot of sense and the performance of the module may not really be a big issue.

Unfortunately, Mandrill handles webhook keys in a clunky way. There is only a single key and it's generated by Mandrill. Mandrill begins sending requests signed with the new key immediately and will retry the requests every few minutes until a 200 response is received (IE, the app is updated). With a large volume and/or a slow deployment process it could lead to a lot of repeated requests that fail.

What do you think about having all three solutions implemented?

---

Regarding our configuration:

We were using the DJRILL_WEBHOOK_URL. Right now I'm defining MANDRILL_X and the ANYMAIL['MANDRILL_X'] in the following way:

MANDRILL_WEBHOOK_URL = '<full url>'
ANYMAIL = {
    'MANDRILL_WEBHOOK_URL': MANDRILL_WEBHOOK_URL,
    ...
}

We have had some issues with mandrill in the past and use the mandrill module and these settings directly in a few other spots. Once I get this working I'll be cleaning up the settings where I can.

---

And finally, so that you have a bit more information regarding Mandrill configuration...it's possible to create a webhook in Mandrill in two ways:

1. Creating an inbound routing rule which lets you set the recipient part of the email address for a domain. Tracking can be added to this webhook later.
2. Creating a webhook via Settings > Webhooks. It has tracking options but I don't see a way to add inbound routing to an existing webhook.

For our domains we created the inbound webhook and then add tracking options to it so we end up with a single key and a single webhook URL.

[medmunds]

Thanks for all the info, and for the PR. I'll merge it over the weekend.

With the background you provided, I'm completely reversing my earlier proposal. Solution 3 isn't actually useful, and I'm wondering if we can just go with Solution 1.

That is, I'm wondering whether we could just go with your combined webhook for Mandrill, and not support separate urls for inbound and tracking. That would certainly be simpler, and would only need the existing MANDRILL_WEBHOOK_KEY and MANDRILL_WEBHOOK_URL settings. (Solution 1.)

Or is your last point saying that if you've already installed a particular url for tracking in Mandrill's dashboard, that you can't later specify that same url when creating an inbound rule? If so, then we definitely have to allow a separate inbound url, for people who already set up tracking. But that also means introducing a separate MANDRILL_INBOUND_WEBHOOK_KEY and MANDRILL_INBOUND_WEBHOOK_URL setting for people who need both. (So also solution 2. Ugh.)

(I no longer see any value in Solution 3, Anymail supporting a list of Mandrill webhook keys like it does for basic auth credential rotation. Seamless rotation requires being able to configure the new key at the receiving end before the sending end starts using it, and Mandrill's approach to webhook keys is the exact opposite.)

[jonathanbaugh]

Happy to help!

Solution 2 would be a nice to have feature if the application already using anymail and want to add the inbound hooks. I think it'd be relatively easy to implement. Do you think having both options would be confusing for users?

[medmunds]

It's making the code pretty messy to try to support multiple WEBHOOK_KEY and WEBHOOK_URL settings, depending on which Mandrill webhook(s) are being used (and how). And I'm not sure it really adds value for the user to have two different webhook urls.

I'm going to switch to just .../mandrill/ as the recommended endpoint for all Mandrill events. But I'll maintain the current .../mandrill/tracking/ as an alias for anyone who's already set it up. And that same url will handle inbound events too (despite the name)—which lets current Anymail users add inbound without going through the whole webhook-key-issue process again.

[medmunds]

Released in v1.3. Thanks again for your contribution!