This is a follow-up to this discussion:
As mentioned at the end of that chain, I have begun working on building blocks for this problem. I am new to REST programming and the SmarterMail API, so it is proceeding in fits and starts.
Right now, my focus is on using the message retrieval calls to find messages within a single folder of a single account. In hopes that I can get that working, I have begun thinking about the larger problem of looping through all of the accounts and all of the folders where the message might exists. This part of the problem exposes a massive performance risk: If you look in every folder of every user, the payload will be deployed hours before your search finishes, and performance will be clopbbered for all users while it runs. To limit scope, you need to capture message metadata into a database as the message is being processed. This is the approach:
Use Declude, Declude Reboot, or you own code that monitors the PROC folder. When each message comes through, SmarterMail drops an EML file containing the message itself, and a .HDR file containing message metadata. For this project, the most content is:
- SMTP Mail From address,
- Message From Address,
- SMTP Recipient Addresses,
- and a timestamp.
Parsing the EML file to extract the message subject will make the captured data even more vaiuable.
Both files disappear as the message is processed, which is why the data has to be captured and stored on the fly.
There still seem bot be some users who do not use Declude or Declude Reboot, and honesly, I cannot understand why. It is a powerful supplement to any other product you may want buy or build. Those detractors can probably obtain a similar result, on a next-day basis, by parsing the SMTP and Delivery logs.
Once the database exists, you use SQL queries to find the problem messages and the exact list of recipients for those messages. Instead of checking thousands of mailboxes, you check a handful.