I scheduled some emails through SendGrid without using the "batch" functionality and I would like to cancel them. It doesn't seem like there is a cancel function through the api if not done using the batch functionality.
Is there a way to ensure that the emails fail to send at their scheduled time by doing some hackery, like: temporarily blocking/blacklisting email addresses, closing the account entirely, revoking keys, changing dns entries, etc?
You can stop the scheduled emails by canceling the schedule. You can find more information here. If the schedule has started and you want to stop the emails from being sent then you may need to clear the Sendgrid Queue. More information - Link.
Related
I want to learn different ways how you guys handle incoming emails in Dynamics CRM.
How you make sure that everyone is responding to their emails?
Can we filter incoming emails to get the ones which are not yet
replied? On daily basis we are getting a lot of emails and we want
to have a filtered view where we can only see the emails which are
not yet replied yet.
How you deal with incoming emails which are sent to sales#
accounting# etc.
3A. How you distribute them among different users?
Assigning to them?
Forwarding to them?
3B. And how you make sure that they are replying to those emails?
I will appreciate if you I can learn from your experience on this subject
Use the existing Customer Service module which Microsoft has built for this purpose. Incoming emails create Case records, which are actionable items with associated statuses.
How you make sure that everyone is responding to their emails?
Set up workflows so that unassigned cases cause escalation of some sort (i.e. an email sent to a manager)
Can we filter incoming emails to get the ones which are not yet replied? On daily basis we are getting a lot of emails and we want to have a filtered view where we can only see the emails which are not yet replied yet.
Filter by Case status
How you deal with incoming emails which are sent to sales# accounting# etc.
- How you distribute them among different users?
You can set up routing logic so that cases are tagged with specific attributes, or assigned to specific users based on what address the originating email targeted.
Assigning to them?
This is out of the box case functionality
Forwarding to them?
Set up a workflow to send an email to the case owner or other user
And how you make sure that they are replying to those emails?
A simple option is to review the email history associated with the case. Automating this task is certainly possible but can get complicated.
You could add each email into a queue, and have users process emails out of the queue.
There is a setting to enable this on the entity configuration with the customisations area.
Emails when tracked or synchronised then appear within Dynamics within the queue.
Users then process the queue. This also caters for the scenario where emails do not need a reply - they can be removed from the queue. In this model, the emphasis switches from checking emails are replied to, to checking queues are cleared.
Reply email are linked back to the original email via the Parent Activity Id. So you could build a filter around this.
Create a queue for these to receive email.
The email address that you enter in the Incoming Email field receives all messages sent to the queue.
A) Users can pick items from the queue, a team leader can assign queue items to others, or use bespoke customisation or development to automatically route items.
B) As above.
I was thinking about making a Zimlet that would send mails on specific dates(name dates automatically etc.)m but can't find any way to do so.
I know that exporting from zimbra is not a problem, but is importing scheduled events like this even possible?
Thanks for answers!
Zimbra has no built-in Event system. Still, using cronjobs, a zimlet and a script, that uses the Zimbra-API, this could be achieved.
The Zimlet would function as a setup ui, where users can create the mails, that should be sent regularly.
The script then uses the Zimbra-API to fetch these informations and send the mails.
The script, in turn, is called via a cronjob.
It is possible to schedule emails in Zimbra, on the send button if you click on the arrow next to it a drop down list appears with an option to schedule email for some time in the future, you will see it then in the drafts section until the time is reached to send it
Say I have an app that send an email to a user when something interesting in the system happens. The system would add a sendNotification job to a message queue, which when processed sends out the email.
I want to be able to add these jobs to the queue whenever something interesting happens, but have the system wait for 10 minutes to gather and group all these notifications into one email, rather than send out multiple email within that short timeframe.
How would this be implemented in a system such as RabbitMQ? As far as I can tell delay functionality isn't built in for a start, and you can't update messages once they are sent. So are there any patterns recommended for implementing this kind of thing?
I have a system that sends out periodic job status emails. It would be great if in Outlook they were grouped by conversation for each instance of the job instead of showing up individually.
How does Outlook decide if things are in the same conversation and is there any simple way via metadata/headers to influence/force that?
You will need to update the PR_CONVERSATION_INDEX MAPI property (see http://msdn.microsoft.com/en-us/library/office/cc765583(v=office.15).aspx).
Unfortunately, OOM does not allow to set the ConversationID and ConversationIndex proeprties, so you would need to use MailItem.PorpertyAccessor.SetProperty.
I've set up a Mandrill webhook which will update my app whenever an email hard-bounces or is rejected, so I don't keep that particular email address in my database. The way it works is this: a user gives me an address, I send him a confirmation, and if I don't hear from Mandrill's webhook in 30 minutes, I assume it's OK.
So I ran a some tests with non-existing addresses, and they didn't go too well. Most of them appeared as delivered for hours, long after I'd assumed they were fine.
Also, I didn't account for the delay in receiving webhook batches. One mail bounced at 2:01pm, according to the outbound activity logs, but the webhook history shows a batch being sent only at 2:52pm.
My questions is: how long should I delay my app's assumption of deliverability in order to give Mandrill enough time to detect hard-bounces / rejections and then send me webhook batches? I can live with letting some 5% bad emails going by because of delayed in processing on peak-time or other extraordinary events, but it seems like my 30 minutes isn't enough to catch anything at all...
Not the answer you're looking for, but Mandrill doesn't let you do this. The only way of checking if an email has been delivered is to poll Mandrill (with the message/info.json API). To see if the message is delivered you have to check the smtp_events and look for an event with diag starting with 250. As you've already experienced it may take a long time between delivery and when a message is accessible through the API. In my experience the normal case is around 10 minutes, but it might take many, many hours (this is the case for bounced emails as well as emails that got delivered immediately).
If it is important to you to know when an email is delivered, I would recommend you to switch to another email provider. There are plenty of different ones out there. I've personally used Amazon SES. They're cheaper than Mandrill, and you can expect a delivery notification after a second or so. Do note that Amazon SES is a bit more bare-bone than Mandrill (they don't have support for open/click-tracking, templating, dedicated IP, etc.), so it might not be the right provider for you.