Exchange Online (Office365) email issues?

[mushu]

Mantis: 2.24.3
Email Reporting 0.10.1
Windows Server 2012R2, IIS 8

Does anyone have any hints or tricks for getting mantis to work to grab emails from an inbox and process them as tickets under Office 365? We recently converted over to "the cloud" (ugh) and having problems now getting the EmailReporting plugin to be able to login to the account inbox to grab messages via POP3 protocol. I've got our network folks working on it, but wondering if anyone else has had and/or solved this issue.

Thanks!

[SL-Gundam]

EmailReporting has no support for mfa/2FA so disable for the mailbox in question or use app passwords
Office365 allows disabling protocols on a per mailbox basis. Check whether the POP3 protocol is turned on for the mailbox in question.

https://support.microsoft.com/en-us/off ... 6c4ac95353

[mushu]

Yes, I've ensured that POP is enabled on the account. I still get the following TEST results:

Code: Select all

Operation NOT successful

Description: UserName mailbox
Mailbox type: POP3
Hostname: tlsv1.2://outlook.office365.com
TCP port (optional): 995
Connection encryption: TLSv1.2
Verify SSL certificate: 0
Username: UserName@my.domain.com
Password: ******
Authentication method: USER

Location: Attempt login
[pear_error: message="-ERR Logon failure: unknown user name or bad password." code=-1 mode=return level=notice prefix="" info=""]

I have tried all possible authentication methods in the dropdown and all possible connection encryptions in the dropdown, with the same results.

I have also tried to do the debug settings in config file but that doesn't log anything *until* the connection is made, so i can't see any of the actual server responses while it is trying to authenticate. Hoping someone has more clues for me on this, it is very frustrating (yes, I know this is not the fault of Mantis or the EmailReporting plugin.)

[mushu]

devbugs-exch-settings.PNG (90.45 KiB) Viewed 10209 times

[SL-Gundam]

Mine looks like this
Don't know why you are using TLS. Especially since Microsoft is stopping support for it

Ignore the "Verify SSL certificate" and leave it off during testing. It's a bitch on windows to turn on

Code: Select all

Operation successful

Description: mantis-bug-tracker
Mailbox type: POP3
Hostname: ssl://outlook.office365.com
TCP port (optional): 995
Connection encryption: SSL
Verify SSL certificate: 1
Username: Mantis@domain.com
Password: ******
Authentication method: USER

Weird things like this i usually test with an actual email client. If you can get the mailbox working with the same information your are giving EmailReporting then it should work.
Please also be careful with copy paste for passwords. It's very easy to accidentally include an extra space

[SL-Gundam]

devbugs-exch-settings.PNG

Are these for the Office365 tenant or for the mailbox in question?
I'm asking because that looks a little bit different for me

[mushu]

I thought TLS 1.2 was the latest encryption MS is using? Perhaps I'm confusing HTTP with this though...

So I made my settings match yours, and carefully retyped the password, and still get this:

Code: Select all

Operation NOT successful

Description: UserName mailbox
Mailbox type: POP3
Hostname: ssl://outlook.office365.com
TCP port (optional): 995
Connection encryption: SSL
Verify SSL certificate: 1
Username: UserName@my.domain.com
Password: ******
Authentication method: USER

Location: Attempt login
[pear_error: message="-ERR Logon failure: unknown user name or bad password." code=-1 mode=return level=notice prefix="" info=""]

[mushu]

Your screenshot looks like it's from Windows 10 settings, mine is from the Exchange Online admin panel settings for that account.

[SL-Gundam]

Yes your right.
TLS 1.0 and 1.1 are deprecated, not 1.2

I'm still using the old Exchange admin center. The screenshot was from the initial admin portal

Did you test the account with a normal mail client like Thunderbird in POP3 mode?

[mushu]

So I grabbed a command-line POP3 client that supports ssl/tls and tried it manually from the server, and it grabs the cert and then tried to login and the server returns a bad username/password error message. So apparently the Office365 cloud settings for that account are wonky. I'm trying to see if they are using a different username or password than we have in active directory on premises for that account. I also had them disable mfa/2fa for the account and that did not make any difference either.

Stupid microsoft.

[SL-Gundam]

Testing the login information should be easy enough using webmail.
You can also check the sync status of a mailbox in the admin portal.

Please let me know the results

[CapCaveman]

So, this worked for me:

Mailbox Type: IMAP
hostname: outlook.office365.com
TCP Port: 993
Conn. Encryption: SSL
Verify SSL cert: No
Auth. Method: USER
create project subfolder structure: No

Now, try a Complete Test. Notice the result page will be empty (blank), but the emails will download. Give it some time. Also, check in 365 the junk mail folder. Seems some emails go there and won´t download. Just check and specify as not Junk.

Email reporting version: Email Reporting 0.10.1

[mushu]

Code: Select all

Mailbox Type: IMAP
hostname: outlook.office365.com
TCP Port: 993
Conn. Encryption: SSL
Verify SSL cert: No
Auth. Method: USER
create project subfolder structure: No

Thanks for the post but we need to do it via POP3 so the messages get deleted as they are sucked down. Too much traffic to try to remember to get in and delete everything unread in the mailbox.

Have you tried to download the messages using POP3 on the appropriate port yourself?

[mushu]

Learned a bit more. Apparently if the mailbox is on premises (on-prem) then EmailReporting will work just fine. But when the mailbox is migrated to "the cloud" in O365, it requires MFA/2FA and Mantis does not have that authentication method built in. The POP3/IMAP method will no longer access the mailbox at that point. It is appearing that the best solution will require adding OAuth2 authentication to Mantis/EmailReporting unfortunately.

My other idea of grabbing the email messages and saving them as separate text files, then piping them into the EmailReporting script appears to not be feasible due to how granular the network operations code is in the plugin. I couldn't see an easy way to make the flow of code "jump around" to the sections it needs and bypass the server commands.

Looking like we will need to abandon Mantis as a ticketing system at this point, but it is a great program and we all enjoyed using it! Not sure what we will move to but all I can say is that the code needs to keep up with the rest of the world, even if it is open source...

:-)

[cas]

There is a way around this bloody issue. What we will setup is a dummy mailbox non O365 and use that for receiving the mails.(either directly or by autoforwarding the O365 email). Worthwhile considering