Fetch email from o365 - modern way

Hi there,
is it possible for Best Practical or a forum member to create an understandable howto on fetching mail for RT5 from O365 using modern authentication instead of basic SMTP credentials?
I know of a thread on here that mentions one or two python scripts that could be of help, but i (but maybe more users) would very appreciate a proper write up for connecting RT5 to o365 in a proper way.

You can see this tool for more information:

ok looking good!
so this needs to be installed like a module?

It’s more of a standalone tool that you’d schedule with cron, I don’t believe you need to configure anything within RT for it. Just point it to the rt-mailgate web endpoint like the /etc/aliases file examples

Root cause of the issue responsible for what you describe is that that fetchmail does not understand OAuth2 natively. Not yet, anyway.

What you can do is use a wrapper script on fetchmail to or use the plugin as described above and make sure you configure plugin correctly

ok gave it a try. seems to work. had to tinker a bit too long with the tool. Not sure why a client secret has to be created in the AAD application (per docs) as it is not used within config example and works without it.
also, the tool needs to read a top-level mailbox folder. i was not able to discover how to read a subfolder of “Inbox” for example. It fails fetching in a subfolder using backslash or forwardslash, so i had to use a toplevel folder in a mailbox for now.

Trying to make this thing work.
After installing a gazillion missing Perl modules, the tool is working, but gives me this error:

fetching mail using configuration ./config.json
unable to get user access token for user rtadmin@amended_domain.it request failed with status 400 Bad Request at /root/app-wsgetmail-master/bin/…/lib/App/wsgetmail/MS365/Client.pm line 234.

Here is my config.json file:

{
“command”: “/usr/bin/rt-mailgate”,
“command_args”: “–url http://rtbkd.test.bkd/ --queue SistemiCentrali --action correspond”,
“command_timeout”: 15,
“recipient”:“sistemi.centrali@amended_domain.it”,
“action_on_fetched”:“mark_as_read”,
“username”:“rtadmin@amended_domain.it”,
“user_password”:“amended”,
“tenant_id”:“amended”,
“client_id”:“amended”,
“folder”:“Inbox”
}

I am sure that the user and password are correct, because we are still using that credentials with the standard authentication.
Any hints? Anybody else with this problem?

Thank you in advance
Cris

not sure what you’ve done to prepare/configure the Azure AD application.
Did you configure the application exactly like on the screenshots in the doc directory of the tool? Permissions need to be “delegated” type and the list of permissions should mirror the list on the screenshot, “default client type” switch needs to be on “Yes” under authentication. etc.

I got it working now using those settings.
tenant id in config file = directory id of AAD application.
client id in config file = application id of AAD appliction.

app-wsgetmail/doc at master · bestpractical/app-wsgetmail · GitHub

Thank you @JayST for your reply.
Here are our settings:

looks good.
hows the screen under authentication looking, Like this? (could be a bit different wording)
image

Mine is a bit different:

We tried again, creating a new cloud-only user.
This time the authentication apparently goes well, but we have another error right after:

fetching mail using configuration ./config.json
failed to fetch folder detail 500 Can’t connect to graph.microsoft.com:443 (certificate verify failed) at /root/app-wsgetmail-master/bin/…/lib/App/wsgetmail/MS365.pm line 230.
unable to fetch messages, can’t find folder Inbox at /root/app-wsgetmail-master/bin/…/lib/App/wsgetmail/MS365.pm line 276.

processed 0 messages

There seems to be a problem with certificate validation, but I don’t know how to understand which certificate is it trying to validate (the one from the remote HTTPS site?) and how to change the way validation is done.

no idea what goes wrong there.
cert verification should just go fine for graph API. does not need configuration or altering validation. Are you restricted by a firewall for outbound traffic on port 443 in some way?
perhaps not allowed to connect to all of the internet, and as a result not able to verify the cert?

Yes, we are behind a corporate proxy, but there’s no problem connecting to secure sites.
I just tried with wget on the same server where app-wsgetmail is running, and it retrieves from graph.microsoft.com:443 without problems.
I’ll try digging some more.

Found this. Applying the accepted solution allowed me to connect successfully (although, if I understand correctly, it removes hostname verification, which may be undesirable).
One of the comments says something about problems on Centos 6. I am on Centos 6 (I know, I know, I should upgrade that server as it’s EOL) so maybe this is the problem.

I need to read email from a mailbox that’s not the default mailbox of the authorized user.
Trying to explain better: we have an administrative user which is authorized to read all the mailboxes that have corresponding RT queues. Previously, with the IMAP mechanism, we were able to access the correct mailbox by specifying “adminuser/mailbox” when authenticating with fetchmail. Now this does not seem to work anymore. How do you setup the config.json file to be able to access another mailbox?

can you change the recipient in the config file to one of the RT queue mailboxes and specify the mailbox in that way?

Did that already. Apparently specifying the recipient does nothing with respect to selecting the correct mailbox. I suspect it simply filters the messages once you have had access to the mailbox/folder.
I even tried setting it to a non-existent user and the result is the same: processed 0 messages.