Chicago media reporter Robert Feder shared an interesting story today. The Chicago Tribune recently sent a simulated phishing email to employees, to test them to see if they would "fall for" the phish and click on the links in the email message. This is somewhat standard in the corporate world and is used as a measure of whether or not an employee might need more email/internet security training. All good. Less good, though: using content that suggests that employees might be up for bonuses. "Coming at a time of pay cuts, furloughs and newsroom closings, Tribune staffers were incensed by the scam," says Robert. Oof. Good to hear that the company did apologize and admit the that the choice of language was a bit tone deaf. I hope others will learn from their mistake.
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.)
- Configure your Google account to use 2FA.
- Configure an "app password" to put in your Postfix configuration.
- Assuming your Postfix install already has SASL support, configure /etc/postfix/sasl_passwd to add this line:
- Set your "relayhost" setting in the Postfix main.cf to point to [smtp.gmail.com]:587.
- 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!
I'll be trying the SPAM Western Pasta Salad recipe here shortly!
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!]
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.
(Psst--hiring for deliverability? He's somebody you should consider. He's looking, and he's a smart person.)
- 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.
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!