RangerMSP Business Automation for successful ITs


Go Back   RangerMSP Forums > RangerMSP Software Discussion Forum (CCRM)
Search Today's Posts Mark Forums Read

Thread Tools Search this Thread
 
July 2nd, 2020, 11:23 AM
nextechinc
 
Posts: 11
In order to work around some of the recent Microsoft 365 security requirements, we now have e-mail forwarding to a traditional POP3 mailbox. Since this change, employee replies to ticket e-mails no longer show up in the ticket history. They still get delivered to the appropriate recipients, they just don't make it to the ticket history. Customer replies still make it to the ticket history, I just can't figure out why employee replies don't.
 
July 2nd, 2020, 01:23 PM
Support Team
 
Posts: 7,510
Thank you for posting this.

We will need to review the log files in order to learn more about this.

Please zip the \Logs folder and email it to us (support@) or upload to Drive/Dropbox and share with us.

Hope this helps.
 
July 2nd, 2020, 11:49 PM
Grtaeme-ACT
 
Posts: 17
We reported the same issue yesterday, emails not logging in tickets but being delivered to clients, the emials to be logged just sit in the mailbox unprocessed by the email connector.

We were today by Commit/Ranger support it was a Microsoft 365 issue and to report it to Microsoft...
 
July 6th, 2020, 03:17 AM
Blueplanet
 
Posts: 33
We have the same problem, have you manged to fix it?

Paul
 
July 6th, 2020, 07:45 AM
Grtaeme-ACT
 
Posts: 17
Quick update for anyone interested, we have had a Microsoft Pro Support engineer look at the mailbox and they cannot see anything that should stop it working, and no recent changes.

Commit/Ranger support suggested another user got this working by using a different mailbox, my feeling is that this will be a temporary fix as any updates will be rolled out to all Microsoft 365 mailboxes.

We are going to try moving the mailbox we sue to a different 365 cluster to see if that resolves it but this takes time and will only be a temporary fix.

Still think this needs more investigation from Commit/Ranger, if this is a global Microsoft change being rolled out as initiall suggested it will stop the Email connector working for everyone soon.
 
July 14th, 2020, 01:32 AM
Grtaeme-ACT
 
Posts: 17
Just another quick update for anyone interested, after lots of help from Ranger support and Dina specifically the issue is resolved. Unfortunately not through anything we did I don't think it seems there was an issue with Office 365 and we were advised by Microsoft Pro Support that there was an issue with impersonation through Exchange Web Services.

We do still have the issue that the old emails will not process but everything new is going through as expected.
 
July 14th, 2020, 06:02 AM
Support Team
 
Posts: 7,510
Thank you for sharing!
 
October 23rd, 2020, 01:21 PM
nextechinc
 
Posts: 11
We're still having this issue. We have a distribution group set in O365 that forwards to an external contact (support@pop.ourdomain.com) which is just a basic dovecot POP mailbox. Ranger has no problem pulling from that mailbox, and customer e-mails get processed correctly. Employee e-mail responses get processed and sent to the customer, however these employee responses don't show up in the ticket history at all.

Interestingly enough, if I reply directly to support@pop.ourdomain.com, rather than support@ourdomain.com, the reply does show up in the ticket history, but does not get sent to the customer.

So there's some routing logic somewhere that is getting fouled up by this workaround we've done, but I can't seem to figure out if there's any way to fix it.
 
October 23rd, 2020, 01:49 PM
Support Team
 
Posts: 7,510
Thank you for posting this. That's interesting.

Using distribution groups is always prone to problem with the email connector.
The way the Email Connector files employee replies is as follows: The reply to the customer is Bcc'd to the email Email Connector public email address. So the email getting filed is actually the email sent to the customer. The email connector receives it, knows it is a reply to a customer a files it under the customer account and Ticket.

However, with distribution lists, Exchange/365 is trying to be "smart" and because it knows that this email was sent by the same address it does not brings that email as an inbound message that can be popped- and as a result, there's nothing to file, i.e the employee reply is sent to the customer, but not received back, as Bcc, to the mailbox.

Therefore, the recommendation is to connect the Email Connector to the a mailbox that represents the public email address, usually supports@ , unlike using any mailing or distribution lists that are more virtual. For reference, Shared Mailbox vs. Distribution List, and in the case of the Email Connector, use a real mailbox vs. any group address or distribution list setup.

Then, when no-one but the connector works with this mailbox directly, and that mailbox represents the Support@ address itself, when it sends Employee replies to the customer, such replies do come back (as it sends them to itself as Bcc) and are expected to get filed.

We would also be happy to review your log files, however, I doubt that we'll see anything new there in this case.

Hope this makes sense and helps.
 
October 23rd, 2020, 02:11 PM
nextechinc
 
Posts: 11
The problem with using Office 365 directly now, is that since we're an indirect CSP, we're subject to their security requirements. Therefore we can no longer use basic authentication to pull mail out of a POP3 mailbox.
 
October 23rd, 2020, 06:00 PM
nextechinc
 
Posts: 11
I've been fighting to figure out a workaround for this today, and I'm having a hard time understanding why this needs to be so complicated. What is the reason for creating the BCC in the first place? If the mail is getting plucked out of the mailbox, and sent off to the customer why does yet another message have to be created, to sit in the Inbox and be processed again. Seems ridiculous, slow, and unnecessary. When the connector picks up the message the first time just drop it into the ticket history and be done with it.
 
October 26th, 2020, 09:32 AM
Support Team
 
Posts: 7,510
The same email (Employee reply) that is sent to the customer is also sent as Bcc'd to the Public Email Address.

This way the Email Connector ensures that the email was sent to the customer - meaning it files the actual email message sent to the customer, unlike only filing a reply message under the Ticket, one that might not has been sent to the customer, so that's safer.

Such an email message contains specific information, as part of the email header, that allows Email Connector *to save the email under the Ticket History and avoid creating various email loops.
It is necessary for such email to be received back as an inbound email. From our experience, using the distribution list might indeed break this because some mail servers try to "optimize" things while this ends up breaking the system - that is - preventing the email message from getting saved under the Ticket.

Therefore using the distribution list as a mailbox for Public Email Address is not recommended.

Regarding the basic authentication and POP3 support - based on the following update by Microsoft, they have postponed the changes, originally planned for October of this year, to later in 2021.
It is possible that you may consider enabling POP3 for your main 365 mailbox and it'll work, without needing any mailing list (i.e. a dedicated support@ real mailbox that the Email Connector will pop and send from directly).

https://techcommunity.microsoft.com/...e/ba-p/1275508

Besides, we're still reviewing a few more options here, we may add another update later, once we know whether any of the other options worked.

Hope this makes more sense and helps.
 
October 26th, 2020, 10:43 PM
nextechinc
 
Posts: 11
In case anyone else is still struggling with this, I finally came up with a workaround. I ended up setting up a connector in M365 for our postfix server, and created a transport rule to forward mail to support@mydomain.com to it. I believe the distribution group forwarder would have also worked, as the error that was breaking the ticket history also occurred with this configuration, but I had already put in the effort and wasn't going back.

The error in question, in postfix was:
Oct 26 09:14:26 ip-172-31-42-129 postfix/pipe[3427]: 18E91AEE6E8: to=<support@mydomain.com>, relay=plesk_virtual, delay=0.8, delays=0.77/0/0/0.03, dsn=5.4.6, status=bounced (mail forwarding loop for support@mydomain.com)

After more googling, I discovered that postfix adds a "Delivered-To:" header upon a message receipt, which it then checks in subsequent messages to detect a forwarding loop. Stripping that header using the method below allowed the BCC to be processed successfully, and technician messages once again appear in the ticket history.

Added to /etc/postfix/main.cf:
header_checks = regexp:/etc/postfix/header_checks

Added to: /etc/postfix/header_checks
/^Delivered-To:\ support\@mydomain\.com$/ IGNORE

Then:
postmap /etc/postfix/header_checks
service postfix reload

That successfully strips that header from the receive transaction, while leaving the forwarding loop check in place for all other mailboxes.
 
October 27th, 2020, 06:02 AM
Support Team
 
Posts: 7,510
Thank you for sharing this!
 
October 29th, 2020, 03:49 PM
nattivillin
 
Posts: 1,146
Weird fix. We had similar issues and jumped through many hoops to get pop working correctly on O365.

At the end of the day, the real problem is that ranger relies on pop3 mailboxes for proper client and tech communication. As pop3 support dwindles, this issue will only get worse....
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search



All times are GMT -6. The time now is 08:27 AM.

Archive - Top    

RangerMSP - A PSA software designed for MSPs and IT Services Providers
Forum Software Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.