I have a project with an single API key in Mandrill. It has three sub-accounts: production, staging, development. I have created a rule that rejects all requests that don't match a small list of domains and I want to apply that rule to both the staging and development sub accounts. The idea is to not accidentally spam clients while we are testing.
I don't see how I can apply the rule to different sub accounts. Is it possible? If not, and I need to create different APIs for each environment, can someone explain when to use sub-account vs when to create different API keys.
As a bonus, when an email matches a rule, is it possible to reroute it to a specified address instead of rejecting it?
I would use separate sub accounts for tracking different systems in a multi-tenant environment (eg you are acting as a service provider for multiple customers or departments via the same Mandrill account).
In your case, I would definitely use separate API keys for each each environment. The main feature you would potentially want to take advantage of is to be able to set one of those keys (eg staging) as a "test key" such that the emails don't ever get sent, they just get tracked in Mandrill so you can verify that they are working.
The last thing you want to have happen is that emails from your non-production environments actually get sent to real users.
The way I typically do things is to have my development system use a non-test key, but only have dummy users whose email addresses all come back to me so I can test things. Then in my staging system, I use a test key with real users (a copy of the production user database) so that any emails that get sent are captured by Mandrill for verification that they are working, but don't ever get forwarded on to the actual user.
I'm assuming that your rejection rule based on a list of domains is intended to achieve the same result that using a test key does - in which case, go with the test keys and forget the rules.
You can't apply a rule to a specific sub account - only to a specific API key.
And no, you can't reroute an email to a different address based on the outcome of a rule - the best you could so is to wire a webhook to somehow notify your system that the rule was triggered so that your system can re-send the email - but that requires custom development work.
Again, if this is actually just an attempt to avoid sending emails to real users when testing, this is what test keys are for.
Related
I am creating a service in which services can upload files from different methods.
One of them is by sending the file to a specific email address that is linked to the app.
I have managed to do so with a unique email address that is the same for all the users (generic#mail.com), but I would like that have a different address for every user (like user_specific_email#mail.com).
I am using MailBox on rails.
Do you know if it is possible ? And if so, is it more secured and generates less risks of bottleneck if a lot of mails are processed at the same time ?
Best
I am in the process of switching the LDAP backend that we use to authenticate access to Gerrit.
When a user logs in via LDAP, a local account is created within Gerrit. We are running version 2.15 of Gerrit, and therefore our local user accounts have migrated from the SQL DB into NoteDB.
The changes in our infrastructure, mean that once the LDAP backend has been switched, user logins will appear to Gerrit as new users and therefore a new local account will be generated. As a result we will need perform a number of administrative tasks to the existing local accounts before and after migration.
The REST API exposes some of the functionality that we need, however two key elements appear to be missing:
There appears to be no way to retrieve a list of all local accounts through the API (such that I could then iterate through to perform the administrative tasks I need to complete). The /accounts/ endpoint insists on a query filter being specified, which does not appear to include a way to simply specify 'all' or '*'. Instead I am having to try and think of a search filter that will reliably return all accounts - I haven't succeeded yet.
There appears to be no way to delete an account. Once the migration is complete, I need to remove the old accounts, but nothing is documented for the API or any other method to remove old accounts.
Has anybody found a solution to either of these tasks that they could share?
I came to the conclusion that the answers to my questions were:
('/a/' in the below examples is accessing the administrative endpoint and so basic Auth is required and the user having appropriate permissions)
Retrieving all accounts
There is no way to do this in a single query, however combining the results of:
GET /a/accounts?q=is:active&n=<number larger than the number of users>
GET /a/accounts?q=is:inactive&n=<number larger than the number of users>
will give effectively the same thing.
Deleting an account
Seems that this simply is not supported. The only option appears to be to set an account inactive:
DELETE /a/accounts/<account_id>/active
I'm using Mandrill to send emails from my Rails 3 application. In production, I use the API key I set up in their admin console. To prevent dev and test SNAFUs that might email all our users, I've put garbage keys in the development and test environment config and I only put the real key in the production config. Mandrill allows you to create multiple API keys. Does anyone know if there's a way to configure Mandrill such that an API call to send an email using the development or test key will fail unless a certain precondition is met (e.g. email domain matches mycompany.com)?
Mandril now have added test API keys. Read More on their site
Mandrill API keys all function the same and have full access for all API calls in the account. There's not currently a concept of a development, sandbox or test key, or scoping API keys. However, test mode/functionality is on the development roadmap. I don't currently have an ETA, but it's definitely something we're working on.
EDITED TO ADD: As of the time of this answer originally, this wasn't possible. Mandrill does now have a test mode.
There are two possible approaches to creating a "development" API key in Mandrill, which serve different use cases:
Create a Test Key. No emails sent using this key will actually be sent. This is the simplest approach, and appropriate if your testing flow doesn't require you to actually receive your test emails. (You can still see the content of the emails that would have been sent in the Outbound tab.)
Create a live API key, and use the Rules Engine to make it so that emails sent with this key will be automatically rejected unless the recipient address matches some pattern. You should use this approach if your testing flow requires actually receiving the emails you send - for example, if you have an automated end-to-end test of your password reset functionality.
Approach 1: Using Test Mode
Test Mode was added to Mandrill in 2013. To use it, first create a Test Key from the API Keys subsection of the SMTP & API Info section of the Settings tab. The first key you create here will always be a live key, but if you click "New API Key" a second time, you will be able to choose to create a test key:
Once you've done that, "send" some emails using the Test Key (the emails won't actually be sent) and click the Turn on test Mode option from the dropdown menu at the top-right of the screen:
While the admin panel is in Test Mode, if you go to the Outbound tab you will be able to see emails you've asked Mandrill to send with your test API key, as if they had really been sent.
Approach 2: Using the Rules Engine
First, create a new live API key from the API Keys subsection of the SMTP & API Info section of the Settings tab. You must give the key a Description, or you will not be able to refer to it from the Rules Engine.
Next, go to the Rules section of the Outbound tab and click "Add Rule":
From the Rules interface, set up a rule that will reject emails if the API key is your test key and the recipient's email matches some pattern of your choosing. The pattern could be a single email address like testbot#yourdomain.com, or it could be an entire domain, like *#yourdomain.com.
In case you want to craft your own, complicated pattern, note that per the docs, Mandrill uses Python's fnmatch module to match your patterns against email addresses (which uses glob syntax, which you may be familiar with from your shell if you use Unix).
Emails you send using this key to domains matching your pattern will really be sent and show up in the live Outbound tab. Ones that don't match the pattern will not be sent and will show up as "rejected" in the live Outbound tab.
We like to see the emails go out even in test/dev so that we can see things work end-to-end. To prevent issues with customers getting a test email, we configure an initializer (Ruby on Rails) that will substitute the recipient if not production. Don't leave the check up to individual Mailer implementations - someone will forget.
MandrillMailer.configure do |config|
config.api_key = ENV['MANDRILL_API_KEY']
# Set recipients to test#ourdomain.com if we're not in production
if !Rails.env.production?
config.interceptor = Proc.new do |params|
params[:to] = [{ email: "test#ourdomain.com", name: "Test", type: "to" }]
end
end
end
I'm considering adding email addresses to a marketing web app. Currently users are able to sign up and get a subdomain address that they can choose (theychoose.domain.com). So I'm thinking of also offering theychoose#domain.com for an email address they can use.
I've pretty much decided on sendgrid.com for sending email through the web interface which takes care of a ton of sending headaches. I'd also like to avoid setting up an email server if I could so I'm looking for services that allow me to set up an account and then programmatically create addresses when a user signs up. I want to find a service that will deal with all the spam filtering etc.
Also, this probably makes no difference but it's a Rails app.
One possibility is to use Google Apps Premier Edition. The API description can be found at http://code.google.com/apis/apps/gdata_provisioning_api_v2.0_reference.html.
Keep in mind though, that each user will cost $50/year. However, if you make significantly more than that per registered user, then it may be worth it.
I'm planning an XMPP bot system in which a bot is "attached" to a Rails app in background to receive commands and so on. Is is appropriate to use the same account for all apps (40+) and just changed the resource part, like this:
account#host/bot1
account#host/bot2
account#host/bot2
or use totally different JIDs, like:
account1#host
account2#host
account3#host
Pros/cons? Thanks for any feedback!
I'm still learning about this myself, but I've observed that implementing the bots as resources associated with the same bare JID has some characteristics:
XMPP servers may route Message stanzas (but not IQs or Presence stanzas) addressed to one resource to another resource which shares the same JID if delivery fails
The Jabber Session Manager component seems to maintain roster information on the bare JID level, so all the bots will share a XMPP
You want to use unique JIDs, and not reuse same bare JID and change the resource. As Mitch described, sometimes the packet will go to the bare JID, sometimes the full JID. If you're already writing a Robot Army, make a setup script and register the unique names to create the accounts for the Army. It'll test that component as a bonus.
You will drive yourself crazy in 90% of your testing if you just change the resource name.