On 14.02.19 09:00, Piers via luv-main wrote:
I'm all for a good excuse for hacking a script, but a long-solved problem isn't such a use case.
Erik
Thanks Erik,
The software is part of a LAMP stack and is used to import documents from attachments into a CRM and attach them to people's records, convert them to text, index them and them parse them for data.
I am sure fetchmail does a great job for your purposes but the IMAP connection is only the tip of the ice berg so jumping out of the LAMP stack for something that is already part of PHP would increase the complexity unnecessarily tho.
Your problems are not the first time that poor task partitioning has made life more difficult. If you were to let fetchmail efficiently and problem-free handle mail delivery, then you only have to either: 1) Pick the mail out of the inbox in your script(s), or 2) deliver each mail directly to a converting filter if your pipeline prefers that, and can buffer adequately. To attempt to mix up post-arrival grist milling with mail delivery makes no sense, I suggest. An inbox makes a fine buffer between the two temporally disconnected activities, each with its own fluctuating data rate, but any buffer will do. In the past I have scripted a similar system. Received emails had attachments stripped, passed through the grist mill, and reports forwarded to appropriate recipients. I let mail utilities handle mail, and kept the back end as a separate back end. Easy to test, and easy to keep working. Erik