Check Inbound Mailboxes increased failures in 25.1.2

We are On Site on the latest version of Enterprise, v25.1.2

Since the upgrade to v25.x we've had an increased number of failures on Check Inbound Email with errors like:

Reason: "cannot set deleted flag"

Reason: "Invalid header value for Sender string"

Reason: "the single id was not found in response"

 

I've also received a lot of feedback on missing emails/cases, where customers claim to have sent something but we never received it.

Any thoughts on how to debug these issues?

Francesca

Parents
  • Hi Francesca!

    These type of problems can be a bit tricky to sort out, but one thought that does cross my mind is whether there are multiple processes that might be polling the corresponding inbox.

    The "id was not found" message seems to imply that the message is not on the server when the Sugar process tries to read/mark as deleted, though it was there when the Sugar process initially got the list of message IDs. If another client/process is polling the same inbox, I can see where it could create a scenario where the other client might remove the message before the Sugar process completes its polling tasks.

    That might be the reason why you are also getting the error indicating the delete flag cannot be set. 

    Alternatively, you might want to add some custom logging code to the related code. The polling process is kicked off by pollMonitoredInboxes() in modules/Schedulers/_AddJobsHere.php. It is a rather lengthy method, but it would be a good place to start when it comes to adding some additional logging.

    In the past, I've seen some odd things such as malformed headers in a single message create problems for the polling job, causing it to halt retrieval for that mailbox. Conversely, I've also seen situations where someone might have an invalid email address somewhere in the FROM, TO, CC, etc. cause problems when sending, which may explain the sender string error you are seeing. One example of that which comes to mind is a scenario where the email address had a space in it. 

    Hope that helps. 

Reply
  • Hi Francesca!

    These type of problems can be a bit tricky to sort out, but one thought that does cross my mind is whether there are multiple processes that might be polling the corresponding inbox.

    The "id was not found" message seems to imply that the message is not on the server when the Sugar process tries to read/mark as deleted, though it was there when the Sugar process initially got the list of message IDs. If another client/process is polling the same inbox, I can see where it could create a scenario where the other client might remove the message before the Sugar process completes its polling tasks.

    That might be the reason why you are also getting the error indicating the delete flag cannot be set. 

    Alternatively, you might want to add some custom logging code to the related code. The polling process is kicked off by pollMonitoredInboxes() in modules/Schedulers/_AddJobsHere.php. It is a rather lengthy method, but it would be a good place to start when it comes to adding some additional logging.

    In the past, I've seen some odd things such as malformed headers in a single message create problems for the polling job, causing it to halt retrieval for that mailbox. Conversely, I've also seen situations where someone might have an invalid email address somewhere in the FROM, TO, CC, etc. cause problems when sending, which may explain the sender string error you are seeing. One example of that which comes to mind is a scenario where the email address had a space in it. 

    Hope that helps. 

Children
  • Thank you for the tips  ,

    I don't have multiple jobs doing polling of a sinble mailbox
    I have a number of mailboxes some Create cases and others are processed by a custom script that creates Leads (responses to marketing emails since we don't use Sugar Market).

    Occasionally someone will send an email to two different mailboxes (like info and orders), both of which are related to Cases, and I sometimes see duplicate entries in the Case since the Case number is in the subject line.

    I've seen emails stuck for malformed headers in the past but this is not the case.

    I'll add some logging and let you know if I find something that is not a quirk of our instance.

    Thanks again!

    Francesca