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 _______________________________________________ luv-main mailing list [email protected] https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
