Engine Yard’s E-mail Systems

To allow your slices to serve web pages as fast as possible, we offload all of the mail processing load to a set of dedicated environments which handle incoming and outgoing e-mail on your behalf. In general your slices should never need to have a full-blown MTA installed on them, except when you have such a large volume of e-mail that you need a dedicated mail processing environment of your own.

Each of our clusters comes with a dedicated outgoing e-mail handling environment. This consists of a pair of slices running Exim, which have port 25 connections load balanced between them. You should configure your mail sending process (ActionMailer, etc) to send e-mail to the hostname ‘smtp’ on port 25; DNS and the load balancer will do the rest.

These slices are configured to accept mail from all slices in the cluster, and forward them to their eventual destination. A small amount of filtering is done to remove known dross (such as e-mails which do not have a valid sender address) but no explicit content filtering is done.

Any e-mail that can’t be delivered to the recipient immediately is fed to a “deferred” server, which queues all e-mail for retry and (hopefully) eventual delivery. This helps keep the queues small on the primary servers, which in turn keeps the mail flowing at maximum speed.

All outgoing e-mail from a cluster will, by default, appear to come from a single source IP address, and this address varies from cluster to cluster (you can find out what it is by resolving the TXT record for _spf.eyXX.engineyard.com, with appropriate cluster ID substitutions). If you desire your mail to come from an IP address only used by you (to isolate your sending reputation from other customers’ behavior), please see our E-mail deliverability guide for more details.

It should go without saying that we do not tolerate the sending of any e-mail which the recipient of that message does not want, and it is your responsibility to ensure that the e-mail addresses you send to actually want the message you send to them. Any violations of this policy will be dealt with as per our Terms of Service.

Incoming E-mail

We split up our incoming e-mail processing into two separate systems. As part of your hosting package, you can host your domain’s e-mail with our e-mail service provider, MailTrust. This service is designed to be used for your “human-readable” e-mail, such as your employees’ mail accounts, as well as role accounts.

Your MailTrust e-mail account is not intended to be used for processing bounces and other “non-human-targeted” e-mail—MailTrust prohibits this usage in it’s Terms of Service. Instead, we have dedicated environments on each of our clusters that are intended to receive all of this e-mail, and then allow you to process it into your application via POP3 or IMAP retrieval.

MailTrust

If you need to host “human-readable” e-mail, such as for your employees, then you can use the 15 free e-mail accounts that are bundled with your Engine Yard service. Since we’re not experts at the complicated issues involved in filtering spam and such, we outsource our customer e-mail service to MailTrust. This e-mail service provides a raft of spam-filtering options, web-based account management, and POP3, IMAP, and web-based access to your mailbox.

All Engine Yard customers are entitled to use MailTrust’s services. All you need to do is open a ticket requesting that the service be setup, describing the domain for which you wish to receive mail and the e-mail accounts you want to be initially setup, and we will handle all the details, and provide you with a login to manage your accounts via MailTrust’s web interface.

Once that is done, your DNS needs to be updated to point to mx1.emailsrvr.com and mx2.emailsrvr.com (we will do this for you automatically if your DNS is hosted with us), and the e-mail will start flowing. To retrieve your e-mail, you can use the following settings in your e-mail client:

• Server: secure.emailsrvr.com
• Username: first.lastname
• Password: As configured for your account
• TLS / secure connection: on

Or go to https://webmail.mailtrust.com/ and login to the web-based e-mail client.

Cluster E-mail

Most applications that send e-mail have a need to receive e-mail as well—bounce handling is the primary reason, but an e-mail based interface to your application can be a handy service extension. The typical requirements for this service are a lot different to those of a “human-readable” e-mail system. You’re usually not so worried about spam filtering, and the primary focus is on speed and reliability rather than features like a webmail front-end.

To satisfy this need, each Engine Yard cluster has a dedicated environment which is setup to receive e-mail and make it accessible to the slices in that cluster. While there is basic spam-filtering in place, the setup isn’t designed for a heavy and clever spam onslaught, and if detailed spam-filtering is required, we recommend you perform that processing on your slices as you receive the e-mail.

One common issue with this service is that it is only accessible within the cluster—you cannot login to the POP3 or IMAP servers from outside the cluster. This is by design, as the service is only intended for e-mail destined for your application, and mail which will be used by humans or programs in other places should be sent elsewhere. If you need temporary access for testing purposes, we recommend using an SSH tunnel through your slice.

Another caveat with the cluster e-mail service is that the e-mail you send to it must have a different destination domain to your other e-mail. For example, if all your staff have “myname@example.com” e-mail addresses, then you can’t have your bounces going to “noreply@example.com”, because the MX records for the “noreply” address needs to point to our cluster e-mail environment, and the other addresses need to go to MailTrust (or your third-party e-mail service provider). Our recommendation to get around this is to use a subdomain, such as “app.example.com”, and get the e-mail that you want to be processed by your application to addresses with that as the domain.

Speaking of e-mail addresses, there are plenty of uses in an automated e-mail system for “catchall” addresses, which don’t require you to configure each username separately, but which just deliver all e-mail for a domain to a single mailbox. Common uses for this are to encode the recipient e-mail address in the sender address, so that bounces are easier to track, and also when you want to use the recipient address to route e-mail to a different user or part of your application, and it’s not feasible to know all those accounts in advance, or if a single script will be processing all of that e-mail.

Also, we can configure a “subdomain catchall”, which routes all e-mail for all subdomains of a given domain into a single mailbox. This is useful, for example, if you host customer instances of your application on separate subdomains, and you’d like to maintain consistency with the e-mail addresses that are used to send into the application. With a subdomain catchall configured on “example.com”, any e-mail address for any subdomain (such as “incoming@foo.example.com” and “noreply@wombat.example.com”) will all get delivered to a single mailbox (usually “catchall@example.com”).