Let's send mail...through Gmail!

With a bit of help from an online tutorial, I've figured out how to relay outbound mail through Gmail. (Of course, that means that I'm sending mail out through a specific Gmail account, not just randomly relaying a bunch of mail through Gmail as if it were an open relaying mail server.)

There are a few different handy things you could do with this. For example, you could send notifications or alerts to your Gmail account without having to worry about the sending reputation of your alerting server, hoping that mail doesn't land in the spam folder. Or if you're running Linux at home and don't have a dedicated IP address and/or it's not easy for you to relay through somebody else's mail server, here's a way for your laptop to send email using Gmail. System alerts, crontab output, whatever, you could configure it to automatically relay it through Gmail.

I am sure that this doesn't work very well as a spam engine. Gmail has some very restrictive rate limiting in place and you're not going to be able to relay millions of email messages through this particular conduit.

From a security perspective, I feel good about this process. I'm using Google's "Two step verification" 2FA with both a security key and codes from an authenticator app. Then I set up an "app password" to place in my postfix configuration. That app password allows me to send/receive mail, but does not allow anyone to login to the Google account nor can they change any account settings. You really should be using 2FA to protect your own Gmail account (but avoid using the SMS step if at all possible).

Let's get started. I'm mostly just working from this guide. (The colors in that guide are such that it's difficult for me to read -- apologies if that's the case for you as well. Copy and paste the text out into a text editor if needed.)

1. Configure your Google account to use 2FA.
2. Configure an "app password" to put in your Postfix configuration.
3. Assuming your Postfix install already has SASL support, configure /etc/postfix/sasl_passwd to add this line:
   smtp.gmail.com:587(tab)youruserID@gmail.com:app-password-goes-here
4. Set your "relayhost" setting in the Postfix main.cf to point to [smtp.gmail.com]:587.
5. Run "postmap /etc/postfix/sasl_passwd" and "postfix reload" and test!

In my case...it just worked! And it's pretty slick. Here's a couple of things to keep in mind:

• The number of messages you can send per day is pretty low. On a new account it seems to be top out before you hit 25 messages. Maybe you can send more with an account that has a long good history, I'm not sure. We'll see. But don't expect to send a ton of mail this way.
• Gmail's going to rewrite the from address to be your Gmail address. The original from address will end up in the "X-Original-From" header.
• Optional: You could get fancy and configure /etc/postfix/header_checks so that mail is relayed via the Gmail conduit ONLY if a particular x-header is present in the email message being sent. I tested this and it seems to work fine. One question is, can I set up multiple accounts to relay through, choosing a certain account when sending to/from certain people? I might need to test that.

Even with the message volume limitations being pretty restrictive, I'm probably going to get some good use out of this, myself. And I hope you will, too!

The Ultimate SPAM Cookbook

Sales of Hormel's deliciously salty SPAM are up in the US during this challenging time, thanks to thrifty shoppers like you and me. Are you running out of ideas of how to cook your spam? Fox Chapel Publishing has got you covered with the new Ultimate SPAM Cookbook.

Miriam Di Nunzio of the Chicago Sun-Times has shared a few of the recipes passed along from the book, and you can click here to purchase the book directly from Fox Chapel.

I'll be trying the SPAM Western Pasta Salad recipe here shortly!

AMP: The next big thing? Not at Outlook.com

Once upon a time I asked if AMP dynamic content functionality was going to be "the next big thing" as far as email is concerned. Google's got support for it in Gmail, and Verizon announced future support for it in Yahoo Mail, but it looks like Microsoft is walking away from it. 

This post on Microsoft's Outlook Blog has a new update added to it, explaining that Microsoft will not be proceeding with AMP support in Outlook.com/Hotmail:

Update (September 9th, 2020): Today we are announcing that, based on the results and feedback we received, the developer preview of AMP for Email will end on October 1st. 

After that date, AMP for Email will be turned off in Outlook.com. Emails that used AMP will instead render using regular HTML; there is nothing extra email senders need to do for this fallback to work automatically. If email senders want to send dynamic emails to Outlook users, we encourage you to leverage Actionable Messages instead.

[H/T: All Things Email. It's a great newsletter-- you should subscribe!] 

Mixed Content and Mixed Messages

Today's guest post comes from Travis Murray. Travis is a Deliverability Engineer based in Canada. He has spent the last five years guiding clients and helping his peers with their deliverability concerns. 

You can connect with him on Linkedin or contact him via email.

(Psst--hiring for deliverability? He's somebody you should consider. He's looking, and he's a smart person.)

The impact of SSL on Email Deliverability has always been a less obvious one. Securing a page does not directly help inbox placement but having insecure content or links in emails can result in fewer people clicking through and having less trust in a brand. 

Since Chrome 68 (July 2018), Chrome has been marking sites connected under HTTP as “Not Secure”. This has generally been easy to explain: SSL is needed if a site collects any kind of sensitive information, such as passwords, payment information, etc. If subscribers are browsing a page over HTTP, even without sensitive information, I still strongly suggest considering SSL. Without SSL, these activities can be recorded or monitored, which is especially risky for subscribers using public Wi-Fi. 

Google has announced that it will be pushing this point further. Over the past few months, it has been moving to have Chrome ensure that secure pages only download secure files. This will become the most impactful in Chrome 86 when it begins blocking insecure images on secure pages.

Image from: https://blog.chromium.org/2020/02/protecting-users-from-insecure.html

You have likely already seen a number of the mixed-content messages if your client has used a page that is secured but the page is pulling in content over HTTP, not HTTPS. With images, this is classified as mixed “passive” content, which is less of a security concern than mixed “active” content, such as an unsecured script file running on a page. This is still a poor security practice that you will want to help them with to prevent issues moving forward. 

Some example scenarios:

• If they use secure landing pages with any insecure images then they need to secure those endpoints as soon as possible. 
• If they use a platform to build their emails that is secured, but their images are insecure then they need to secure those endpoints as soon as possible. 
• If they send emails with no secure links (so no mixed content errors) then … they should still consider securing their endpoints as soon as possible. 

Clients will want to test for these errors on landing pages, inboxes, the platform where they build their emails and any other tools they use that might try to load actual resources from their emails. 

In my testing, larger ESPs like Gmail, Yahoo and Hotmail all proxy insecure images and do not currently show a mixed content warning. This leads me to believe those inboxes will not have issues loading images post-Chrome 86, at least that is my hope. I would not expect smaller ESPs or B2B email clients to do this.

If you have a client who is considering leaving their URLs insecure for some reason, I would leave them with this forward thinking note from the Chromium Blog: “In the future, we expect to further restrict insecure downloads in Chrome. We encourage developers to fully migrate to HTTPS to avoid future restrictions and fully protect their users.”

More Reading:

No More Mixed Messages About HTTPS 

https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html

Gradually blocking mixed-content downloads

https://docs.google.com/document/d/1BRvhtleXB91bkTAq4Xde9vzDoLbcwIuaxaSko3eUQ14/edit

Do you even SWAKS, bro?

Do you know about SWAKS? Maybe not! It is perhaps not very widely known, but it is an amazingly useful tool. SWAKS, created and maintained by John Jetmore, is billed as a "Swiss Army Knife for SMTP" and that's an apt description.

What is it? It's an SMTP testing utility. It lets you watch as it connects to a remote mail server and attempts to send an email message using the values you specify. You can specify the sender, recipient, and which server to connect to. You can also specify body content, if you want, though it has a good default "this is a test" setting.

I use it to test things like:

• Is a domain's mail server properly configured to accept mail for that domain?
• For a domain with multiple MX (mail) servers, do all of them properly accept mail for that domain?
• Does a certain mail server relay mail for everyone, when it shouldn't? (Remember open relays?)
• Double check to see if a blocking issue is still happening, confirming whether or not that issue is intermittent or ongoing.
• How long does it take after message handoff for an email to land in the inbox? (When I start with SWAKS, I can visually observe that SMTP handoff.)

Smart email administrators can do other useful things with this tool, too (check the man page). Test authentication settings, do a virus check test with a GTUBE file, and more. I used it just yesterday to test and see if the IP addresses in the A records listed for "yahoo.co" answer on port 25. (They do not; mail to yahoo.co goes nowhere.)

Like with anything that speaks SMTP, though, you'll want to be a bit careful and not rig up a script to tickle an ISP's mail server hundreds or thousands of times. Doing something "funny" (like trying to use this script to mass validate email addresses) is going to get you blocked or cause other problems, and it won't be the fault of the script!

What is IP warming?

IP warming is the process by which, when you start sending from a mail server on a new IP address, you build up a good sending reputation by limiting your sending to small amounts of mail at first, and you gradually grow your sending volume over the first few weeks. You do that so that your new volume does not "surprise" ISPs and drive them to block your mail. ISPs are suspicious of mail handed to them by servers with little or no sending history; lots of spam comes to them that way. IP warming helps you avoid problems by allowing the sender to introduce themselves to the ISP in a measured and calm fashion. They key is: no surprises; no huge jumps in email volume, no huge numbers of spam reports.