I'm creating an application that downloads an attachment from an email that's automatically generated at midnight every night. The attachment is downloaded into a directory and from there is then parsed into a database.
The main problem with this is that the email generation takes time, so the actually delivery time is unknown. Instead of having a program running the entire time, waiting on it to arrive, it would be far more elegant to have it automatically run the service to download the attachment when the email drops in the inbox, much in the same way as a FileSystemWatcher works on local directories.
The email server runs Exchange 2003
Is there a way, programmatically or otherwise, to cause a service to run on receiving a new email?
Exchange has the ability to run event sinks when certain things occur on the server.
http://support.microsoft.com/kb/324021 shows an example of doing this to create a catchall email address.
Details of the exchange 2003 SDK are at: http://msdn.microsoft.com/en-us/library/ms986138(v=exchg.65).aspx
Related
I have a flow that's triggered on each new email in Gmail under a specific label, it worked fine for a long time until two days ago it started skipping some emails.
I noticed that for the few emails that were skipped there was another email received at the exact same time (matching the same rules) and MS Flow only picked up one of the two.
Is there any way I can fix this issue, that it should trigger on both emails even if received at same time?
I have an application that is creating StreamingSubscription (using EWS managed API) for many hundreds of room resource mailboxes in EXO, and I'm trying to make the code tolerant of a subscription going "bad" and needing to be re-created. Here's the behavior I'm seeing at the moment.
I first divide up the mailboxes into groups according to best practices, and then within each group:
I create a StreamingSubscription for each mailbox
I add all the subscriptions to a connection and open the connection
Some time passes, and the OnSubscriptionError event fires for
one subscription. At this point I find that the subscription in
question is no longer in the connection's CurrentSubscriptions
collection, but I'm able to identify which mailbox it was originally
for.
I then flag that mailbox so that the code will try to re-create its
subscription.
When the code tries to re-create the failed subscription, this error is thrown:
Request failed because EWS could not contact the appropriate CAS server for this request.
Thereafter, my code tries again once per minute to create that subscription, and that same error is thrown each time. This continues for as long as I allow it to run.
If I then stop my Windows service and start it again, all the subscriptions are created successfully, including that failed one.
Here's my question. Why is it able to successfully create the subscription after stopping and re-starting the service, but can't re-create it after the OnSubscriptionError?
I have an SaaS application where each paying customer may have thousands of members they may want to send emails to every now and then.
For now, simple BCC sending via AWS SES have done the trick, but now I am looking at sending personalized emails so I must be able to send the emails one by one.
SES does not have any queue system as per my knowledge, you must make an API call per email. In short, it takes forever to send a batch (my limit is 14 per second), and the user cannot close the page while it is executing (even AJAX calls stop executing if you leave the page, am I right?).
I was thinking of building a system where I store the emails in a database table and then either:
1) Use a CRON that executes every 5 seconds or so, grab a few emails and send them.
2) Execute an AJAX script each 5 seconds that grabs the emails for said logged in customer in a batch ONLY and send them out, but again, if the customer logs out while it executes chances are that specific a batch is interrupted (the remaining ones would still keep sending the next time the customer logs in).
Does any have any better ideas? Or, which of the two above would be preferred?
You should use templates and the SendBulkTemplatedEmail endpoint that AWS introduced a few months ago: https://aws.amazon.com/blogs/ses/introducing-email-templates-and-bulk-sending/.
That way you can send up to 50 personalized emails with a single SES API call. So 700 with 14 calls.
You shouldn't consider queuing them up in a user's browser and sending them by making a series of AJAX requests though. You should only send one Ajax request to start a job. In most server-side languages (any I can think of) you can respond to an HTTP request and still continue doing processing after responding. You can also implement a progress checker in a multitude of ways.
Use a cronjob that sends to the SES SMTP server. This way you can personalize the emails and also control how many emails to send. Your cronjob can sleep in between each batch of emails.
You can use celery to run background job. A user submits a request on a webpage which starts a background job through celery. The background job take care of sending emails. Once sending emails is completed, inform the user by email.
http://www.celeryproject.org/
I have inherited from a colleague who left a system module that integrates with Exchange Online in Office 365. Essentially what this module does is interact with with the remote Exchange service via EWS Managed API; subscribe for push notifications on changes in a user's calendar.
Change events do get posted to our web service and that is fine. And based on the frequency parameter we defined, the status checks messages also get posted on expected intervals, as per description about the subscription keep-alive behaviour.
The problem is, in observation, the subscription does not perpetuate despite responding with SubscriptionStatusType.OK to keep it ongoing. We never send SubscriptionStatusType.Unsubscribe since there is no error condition found in notification in messages. It seems to only last 9 to 14 hours before the Exchange service stops sending any status checks or change notification messages. When we make subscriptions from two separate web servers (different notification callback URLs), their subscriptions seem to die out around the same time.
Haven't found any clues that would cause the Exchange service to cancel/expire our subscriptions. What other conditions might contribute to this premature unsubscribe?
Exchange will "lose" subscriptions on a fairly regular basis, especially in the O365 environment because mailboxes are continually being shuffled onto different servers in order to load balance the entire ecosystem. Even in an on-prem Exchange you can lose subscription if a CAS restarts. Unfortunately to build a reliable app, you have to check periodically that you heard from Exchange via some kind of notification or heartbeat.
How can I trigger a shell script on an email arrival that extracts the mail in a text file? I want to extract the information in the mail, process it to determine the request and send an automated response to that request. The mail will basically consist of a data request and the response will have the requested data in a text file attached to it.
Look into the documentation of your MTA (mail transfer agent). Many of them allow to run scripts or hooks when mail arrives and certain other conditions are met.
If you're using Linux and want a pure client solution (i.e. independent of the mail server software), then you should look at procmail. The documentation contains lots of useful tips and hints how to set up the tool (like performance considerations) and how to properly set up the environment so your script executes correctly.
It also contains examples like a service which responds to "ping" mails.