This repository contains a simple python script that (1) processes an mbox
style mailbox file, (2) parses out (typically) the last message and then (3) re-transmits this using the CLI m365
toolset. While this script can be used in a completely stand-alone manner to extract a message from an mbox
and then send using m365
, it’s main utility is when used in a full ecosystem including an email client and postfix
server.
The CLI m365
offers the ability to use Outlook/Office365 to send emails. However, this tool is not suited to use as a mail client — it merely offers a means to transmit a message from the command line. More useful would be if existing mail clients could leverage m365
natively. Currently, however, this is not available. Therefore, mbox2m365
was created to complete a "missing link" in a full email experience. Using this tool in a configured environment, it is now possible to use any email client to transmit messages using Outlook/Office365.
Even if you’re impatient, it’s a good idea to read this document. However, assuming you’ve already built the infrastructure, assuming you have installed m365
(and logged into your Institution from m365
), have assuming you have setup your email client to email to a dummy local postfix account, then you can install mbox2m365
with a simple
pip install mbox2m365
note at time of writing the PyPI install might not be available. In that case, simply clone this repo and do a
# From the repo root dir
pip install -U .
and fire it off by setting up the monitor on the mbox
file (here we assume the mbox belongs to rudolph
)
cd /var/mail
find . | entr mbox2m365 --mbox rudolph --b64_encode \
--sendFromFile --cleanUp \
--waitForStragglers 5
(Clearly the above relies on entr
. Consult your distro’s repos for the appropriate install. In arch, this is yay -S entr
, in Ubuntu, this is sudo apt install entr
)
Wait! Danger, Will Robinson! Doesn’t this violate security policies? I was told my Institution does not allow clients like thunderbird to connect to the Outlook server to send emails!
Well, the devil is in the details as the saying goes. This solution does not violate policy since the "unauthenticated" email client is not ever connecting/authenticating to the Outlook server. Rather, the "unauthenticated" email client sends messages to a specially configured server that "saves" the emails to a file. Then, a separate program teases out the new arrivals and uses the authenticated m365
program to actually talk to and leverage Outlook to send the email. This separate program that bridges the mail file to m365
is none other than this python module.
So to be pendantic: all credentialing and authentication is handled by m365
and not this tool. The end user is still required to login/authenticate using m365
. If this has not happened, then mbox2m365
will not work.
Again, this repo contains no authentication tokens/passwords/etc.
Let’s get these out of the way first. This is not a full solution for linking a third party email client to Outlook. It gets close, IMHO. The limitations are:
-
This is not a multi-user solution. All email transmitted to the intermediate helper server is added to a single user
mbox
which when processed by this script means all email in thatmbox
will appear to have been transmitted by that user. While in theory it should be possible to support multiple users, either by having a separate helper server per user or by having multiple local users on the mail server and separatembox
files, the current solution is clearly not scalable. It is decent though for the single user case. -
Fundmanentally, this solution is limited first and foremost by the capabilities of the CLI
m365 outlook mail send
functionality. Recent updates tom365
have expanded functionality of this bridge — most notably attachments are now supported. Still pending is fullbcc
support — currently allbcc
recipients are switched tocc
.
Other limitations stem from the fact the bridge needs to process the mbox
file de novo each time mail is received by the helper server. This means that time to process will increase linearly with mbox
size. The real world implications of this are still being explored.
Finally, the bridge does make a best effort attempt to wait until the mbox
has stabilized before analyzing it. When sending emails to multiple recipients, each recipient gets a single complete copy in the mbox
with a single address (the multiple recipient addresses are not conserved in the mbox
but are processed by this bridge). While arguably wasteful, the implication is that while all these recipient copies are appended to the mbox
, the bridge should wait until all have been added before processing. Currently the bridge attempts this by examining the mbox
file size when called, and waiting a small delta time interval and checking if the size has changed again. It will wait until the size is stable before continuing. The TL;DR is this could result in a processing delay.
The migration/adoption of Office365 by institutions often poses issues and problems for users wishing to use different tools for email transmission, particularly on platforms such as Linux.
While it is possible to access various Office365 applications, particularly Outlook, via a web interface, this is often not sufficient for several classes of users, particularly those who find the web interface cumbersome (for instance, the web interface has no (or limited) support for keyboard shortcuts, it is cumbersome if not impossible to automate tasks involving event-driven email) and/or for users who have an existing and efficient email workflow using clients such as thunderbird
or mutt
.
This small repo houses a small and simple python application with some supporting documentation that provides a solution to the problem of sending email from an instituion’s managed domain by leveraging postfix
and some mbox
processing and then using the CLI tool m365
.
The solution requires some seemingly contortuous steps, but in reality is rather simple and can be summarized as follows:
Reading emails that are locked away in an Outlook server is best effected by simply adding a forward incoming email rule from your Institution Outlook Server (IOS) to an externally accessible email provider (such as gmail
), allowing this email to be read easily by tools such as thunderbird
or mutt
.
┌─────────────────────────────────┐
│IOS that receives incoming email │
└┬────────────────────────────────┘
│
└─────┐
│
┌O─────────────────────┐
│forwardRule(<message>)│
└┬─────────────────────┘
┌─────┘
│
┌O────┐
│gmail│
└┬────┘
└─────┐
│
┌O──────────────────────┐
│clientAccess(<message>)│
└O──────────────────────┘
┌─────┘
│
┌┴───────────────────────┐
│thunderbird / mutt / etc│
└────────────────────────┘
The message is now outside of Outlook, and if the Institution does not allow non-authorized clients (often this means they only allow Microsoft tools) to connect to the Outlook server, the following work around will help. Essentially, the outside client should be configured to send email using a properly setup postfix
server that simply copies the target email to an mbox
file.
This mbox
file is then monitored for any changes, and on a change (assumed to mean a new email message has been appended), a new process is fired off to parse off the latest message and then use the command line m365
CLI tool to have the IOS send the email.
┌───────────────────────┐
│thundebird / mutt /etc │
└┬──────────────────────┘
│
└─────┐
│
┌O────────────────────────────┐
│sendmail(<message>) (postfix)│
└┬────────────────────────────┘
┌─────┘
│
┌O────┐
│mbox │
└┬────┘
└─────┐
│
┌O────────┐
│mbox2m365│ <--- this repo!
└┬────────┘
┌─────┘
│
┌O─────────────┐
│m365 <message>│
└┬─────────────┘
│
┌O────────────────────────────────┐
│IOS that transmits outgoing email│
└─────────────────────────────────┘
While all the building blocks to effect the solution exist, the one missing piece is the mbox
to m365
block, which is provided for by this rather simple python script.
Now, edit the transport
file.
sudo bash
cd /etc/postfix
cp transport transport.orig
echo "* local:rudolph" >> transport
For the main.cf
file, do
# Assuming you are still in the /etc/postfix dir in a sudo bash shell...
cp main.cf main.cf.orig
echo "mydomain = pangea.net" >> main.cf
echo "luser_relay = rudolph@pangea.net" >> main.cf
echo "transport_maps = hash:/etc/postfix/transport" >> main.cf
sudo systemctl enable postfix.service
sudo systemctl restart postfix.service
Simply configure your email client to use the machine running postfix
as your email server. All emails will be appended to the transport
user’s mbox
file.