Hi,
we moved away from legacy fetchmail integration and started using wsgetmail with office365.
Most of the time it works perfectly fine, but time to time in random() it happens that wsgetmail stucks and pulls the same message unlimited count even if we delete the message from the mailbox. I tried to setup also lock for the cron, still the issue persist.
Our wsgetmail config:
{
“client_id”: “redacted”,
“tenant_id”: “redacted”,
“secret”: “redacted”,
“global_access”: 1,
“username”: “help@redacted.com”,
“folder”: “Inbox”,
“command”: “/opt/rt5/bin/rt-mailgate”,
“command_args”: “–url=https://redacted/ --queue=General --action=correspond”,
“action_on_fetched”: “delete”
}
2 Likes
Has there been any progress on this? As we were forced to move away from basic auth last week turns out the replacement is very unreliable, it started repeatedly downloading the same 20MB email every 3 mins and filling up the remaining disk size during the long weekend. Luckily deleting the message from inbox worked for us, but this is very worrying
EDIT: correction, the actual size of the msg was 36864K as we had ~60 leftover (10alphanumeric).mime files leftover in /tmp and ~60 similarly named (but not matching) directories that contained the same (though again named differently).
The exact error message from wsgetmail is:
IPC::Run: timeout on timer #1 at /usr/share/perl5/IPC/Run.pm line 2944.
It shows up 2 mins after starting, 2 minutes later the ticket does show up in RTIR, but as the script failed it never gets marked as Read on outlook side, causing it to be retried again and again. I’m unable to share the exact email but it’s quite big with over a dozen attachments (pdf/doc/png).
EDIT: increasing command_timeout to 150 seems to work for this message at least, whether a bigger message won’t cause the same behviour again…
I’m at a similar point in my deployment - I’ve done the wsgetmail --debug --dry-run
I’d like to cron the command to test if the emails will get entered and make tickets but I don’t know how to get it into a cronjob. How did you get it working?
We’ve just increased the timeout to 300, should work for emails up to ~500mb, but it’s a bit weird we’re having to set a timeout at all, size of incoming emails is not a variable under our control and the failure state is spamming your DB with large copies of the same email, doesn’t seem like a feature at all
1 Like