3 min read

Bypassing Exchange/Office 365 email forwarding restrictions or: How I learned to stop worrying and love fetchmail and msmtp

Once upon a time, my school migrated all of its students and staff from a self-hosted email system to Microsoft Office 365 in the cloud. I used Outlook Web Access and its forwarding feature to redirect all mail to my personal Gmail account. Everything was fine and dandy when, in the name of "security", they decided to disable the ability to automatically forward email. So you want me to use Outlook webmail like a peasant?! Not over my dead body! However, email access via POP3 and IMAP was still enabled....mmm, how convenient!

Email forwarding, one way or another

If your organization allows access to your email using standard protocols such as POP3 and/or IMAP, they've essentially given you carte blanche on your emails (at least from a technical perspective!) regardless of whether or not they expose the option to automatically forward your email. With that in mind, it's pretty easy to fetch your email and forward it to your preferred email address via another SMTP server. On Linux, this is easily accomplished using fetchmail, msmtp, and a service that allows SMTP relaying such as Mailgun.

Prerequisites

  • An always-on Linux box, e.g. a cloud VPS
  • fetchmail, msmtp, and SSL/TLS CA certificates used for verification
    • On Debian/Ubuntu, these can be installed with sudo apt-get install fetchmail msmtp ca-certificates
  • Mailgun account (or SendGrid/Postmark/Sparkpost/Amazon SES/your own SMTP server)

I personally prefer Mailgun due to its 10,000 emails/month free tier and ability to send from their sandbox domain without the need to buy your own domain name if you don't already have one.

Configuration

Let's create a .fetchmailrc file in your home directory:

poll outlook.office365.com
protocol imap
port 993
user "USERNAME"
pass "PASSWORD"
ssl
sslcertck
sslcertpath /etc/ssl/certs
keep
mda "/usr/bin/msmtp -a mailgun -- [email protected]"
set daemon 30

Set your username, password, and forwarding destination email address as appropriate.

Now let's create the configuration for msmtp. Create the file .msmtprc in your home directory with the following contents:

account mailgun
from user@localhost
host smtp.mailgun.org
port 587
user USERNAME
password PASSWORD
auth on
domain FQDN_OF_YOUR_LINUX_HOST
tls on
tls_starttls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt

Set the from, host, port, user, pass, and domain fields as appropriate. The from and domain fields shouldn't matter too much. If your Linux host has a public IP with a real domain name, then use it. Otherwise, something like localhost or localdomain should be fine.

Fire in the hole!

With the configurations for both fetchmail and msmtp in place, it's time to unleash the kraken! Run fetchmail -d 30 -N -v and make sure there's no errors, and send a few test emails. If all goes well you should see those emails appear in your destination inbox.

Automation and persistence

Once you've confirmed everything is working properly, you probably want to automatically start fetchmail on boot and make sure it stays running. Here's an example systemd service configuration:

Description=fetchmail-forward
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=USER
Group=GROUP
WorkingDirectory=/home/user
ExecStart=/usr/bin/fetchmail -d 30 -N
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

Caveats and limitations

Needless to say, most organizations have sound reasons for disallowing email forwarding in an attempt to keep communications in house. I am not responsible for anything that may happen to you, directly or indirectly, if you use my guide to forward your work emails against your employer or organization's policies.

From a technical perspective, this method is limited in the sense that it only works if POP3/IMAP/etc is enabled. It is certainly possible for administrators to disable these protocols altogether in an attempt to force you to use Outlook Web Access. If so, breaking your emails out of this so-called prison is substantially more difficult, but not necessarily impossible. Drop me a line via email if you're interested; I don't plan to share the details publicly due to the sensitive nature of the topic.