Configuring Mandrill to work with Domino for SMTP routing

Mandrill is a cloud service which is used to ensure that transactional emails such as password resets get through to end users without falling foul of spam filters. We have had to move to using this with our SaaS XPage apps as it seems to be increasingly difficult to get the Microsoft to play nice when they seem to arbitrarily block our traffic ( there may be some good reason for this that we could address but they don’t seem willing to be helpful and tell us what is tripping the SPAM flags ).
There are two big gotchas that you need to work around when setting up Mandrill integration.

1) SMTP Relay Settings.

You can send emails via Mandrill using modern web APIs or by simply directing your outbound SMTP traffic to the Mandrill servers. We choose to use the second option as we didn’t want to change our coding as this point.
When you sign up to Mandrill you will be given a username and the option to generate some API keys which act as passwords.
The Madrill site also helps you to set the DKIM and SPF settings for your domain. This functionality is very good and detects common mistakes and makes suggestions about how to fix them.
As I described in an earlier blog post there is an issue with the SMTP relay configuration in Domino. Although mandrill advise smtp.mandriillapp.com this address actually redirects to a regional server such as smtp.eu-west-1.mandrillapp.com. You need to add this specific regional server to your Domino config – read the article

2) Mandrill ( and Gmail ) do not like the doc.principal field.

The doc.principal field is commonly used to programatically set the replyto address. When you are offering a SaaS service this becomes quite important as you cannot use the users own email address or you will definitely fall foul of the anti-spam police. Fortunately there is an alternative in the form of doc.INetFrom. The downside is that inetFrom does not work with native Notes mail but that is not an issue in this case.
Be careful though in that you MUST NOT try to use both doc.principal and doc.InetFrom as this will fail for some reason.
There is a  good API report option which will show you that this is the problem. I had to get help from Mandrill ( via twitter ) and they explained that the from attribute has to be set on both the envelope and in the data of the SMTP email. You can see from the example below that Domino is setting the Sender attribute but not the From Attribute.

Once you have stripped out the doc.principals and added doc.InetFrom you get this which does have have a from attribute in the data although interestingly not as an attribute in the API – but it works.

 

Madrill Itself

I must admit to being impressed with mandrill. I had a look at Sendgrid when Mandrill didn’t work but it was nowhere near as impressive in terms of reports, troubleshooting or options. The pricing options on Mandrill look good too although to be able to request support you need to pay or beg via twitter. Once I had raised a ticket the response was swift.
This was their response

Hi Sean,

Thanks for writing in. It appears that right now your system is not supplying a “From:” header in the DATA portion of your SMTP message. The MAIL FROM header is part of the SMTP envelope, and is different than the “From:” address in the actual message data. The address used in the MAIL FROM header can be used to generate a “Sender:” header, but it isn’t used to generate a “From:” header since in SMTP that can be different than the envelope-from AKA “Sender:” header. You’ll want to make sure that your system is generating both a “From:” and a “To:” message header in theDATA portion of your message in order for the message to be able to be sent through Mandrill.

Please feel free to write back if you have any further questions.