The Peculiar Case of Email in the Cloud
Most of the time when I start a project, or spin up a virtual server, it's done in my own basement "server farm". Not too many years ago, if I wanted those services to be public, I'd simply port-forward from my static IP into my personal machines. Or, perhaps I'd set up a name-based virtual host as a reverse proxy if I needed to expose a Web app. The nice thing about hosting projects locally is that when I need to send e-mail messages (usually error notifications), I simply can send them through my ISP's SMTP server. Granted, that's gotten a little more complex through the years, as ISPs are starting to lock down their mail servers and relay mail only for valid domains, but that just means I have to register my static IP properly. It works nicely.
The problem is, the issues I've had with my office Internet connection during the past year really have forced me to reconsider how I host public-facing services. I've been forced, by necessity, to spin up cloud instances and host my numerous projects remotely. I'm actually rather thankful for the need, because although it's not free to host projects remotely, it's fairly inexpensive and much more convenient. I still have my Raspberry Pi colocated in Austria for free (thanks again, Kyle Rankin, for pointing me to that awesome service!). Unfortunately, the Raspberry Pi isn't powerful enough for many of the crazy things I try on-line. It struggles, for instance, to host MySQL. So my main "project" server is a Google Compute instance that I end up paying about $15/month to keep active. That's not cheap, but I actually think I might be able to turn off one of my ESXi machines at home now, and I suspect it uses more than that in electricity.
The problem with Internet-hosted servers is that the lack of a usable SMTP relay makes e-mail very difficult. Yes, it's possible to install Postfix as a full-blown e-mail server, but I have no desire to worry about securing my own e-mail server from attacks attempting to use me as a SPAM relay. And although installing a non-relaying e-mail server certainly is possible, I've found that unless you configure SPF records, MX records and get particularly lucky, e-mail sent from a cloud instance often never arrives at the destination. This is especially true if you spin up servers on the fly.
The truth of the matter is, the only reason I want e-mail in the first place is so I can get notifications from my servers when something goes wrong. I don't ever need to reply to the e-mails. I don't really care where the e-mails come from (address-wise). I just want to have confidence that my notifications will get to me!
If you install Postfix on your server, it's possible to use a Gmail account to send all e-mail on your system. There are a few downsides to this method, but the configuration is simple, and Google's e-mail servers are very reliable. Plus, because you're not acting as an e-mail server yourself, you don't have to worry about having your e-mail rejected by recipients. It's legitimately coming from gmail.com.
The first unfortunate consequence is that for its simplest implementation, you need to enable "less secure apps" to log in to your Gmail account. I actually set up a separate gmail.com account for my server, and then I don't worry about the less secure setting. Thankfully, if this is a concern, it's possible to use two-factor authentication (more on that later).
Second, if you use Gmail as your e-mail relay, every e-mail will be rewritten to come "from" the gmail.com address. For me, this is a non-issue, because I just want my servers to e-mail me reliably when things go wrong. So although this won't be an issue for many servers, it's certainly not a feasible way to provide multi-user e-mail on your server. You can send from multiple users on your Linux system, but every e-mail that is sent will have its headers rewritten so they come from the same address! Thankfully, only the "from" address itself is rewritten, so messages come from an address formed like "User 1 <email@example.com>" and "User 2 <firstname.lastname@example.org>". So even though the underlying addresses are different, you still can tell from which user the e-mail messages are coming. This is useful for me, as it helps determine which app is sending me failure information!
Pick up any e-commerce web or mobile app today, and you’ll be holding a mashup of interconnected applications and services from a variety of different providers. For instance, when you connect to Amazon’s e-commerce app, cookies, tags and pixels that are monitored by solutions like Exact Target, BazaarVoice, Bing, Shopzilla, Liveramp and Google Tag Manager track every action you take. You’re presented with special offers and coupons based on your viewing and buying patterns. If you find something you want for your birthday, a third party manages your wish list, which you can share through multiple social- media outlets or email to a friend. When you select something to buy, you find yourself presented with similar items as kind suggestions. And when you finally check out, you’re offered the ability to pay with promo codes, gifts cards, PayPal or a variety of credit cards.Get the Guide
|Graph Any Data with Cacti!||Apr 27, 2017|
|Be Kind, Buffer!||Apr 26, 2017|
|Preparing Data for Machine Learning||Apr 25, 2017|
|openHAB||Apr 24, 2017|
|Omesh Tickoo and Ravi Iyer's Making Sense of Sensors (Apress)||Apr 21, 2017|
|Low Power Wireless: 6LoWPAN, IEEE802.15.4 and the Raspberry Pi||Apr 20, 2017|
- Preparing Data for Machine Learning
- Graph Any Data with Cacti!
- Teradici's Cloud Access Platform: "Plug & Play" Cloud for the Enterprise
- The Weather Outside Is Frightful (Or Is It?)
- Simple Server Hardening
- Understanding Firewalld in Multi-Zone Configurations
- Be Kind, Buffer!
- Bash Shell Script: Building a Better March Madness Bracket
- Server Technology's HDOT Alt-Phase Switched POPS PDU