We're in the process of revamping how we provide newsletter services to our users and are currently evaluating Newsletter Studio. We're looking into integrating with a 3rd party mail service (eg SparkPost) to handle bounce / non-delivery etc.
While we can use a service as an SMTP relay, many services offer greater feature sets through their APIs. Is there a way to replace the default mailer in Newsletter Studio?
I did see that there are some events exposed, but it doesn't appear that those would quite fit the bill either.
Any suggestions / thoughts? Are there plans to open up the mailer portion such that customers could integrate with third party services a little tighter?
At the moment the bounce-features lives in it's "own area" of the package - we haven't been looking at how and if we could make this extensible but it might be possible.
We have looked at different ways to make the sending service pluggable - one challenge is that we have the concept of render tasks - each email is rendered in a unique process - before its send. Many of the APIs requires a template and then x numbers of merge fields in the payload when creating a send out. Since the render tasks are applied as a C# class that can do "what ever" with the content it's hard to fit without making some major braking changes.
Could you explain more about what would you need in terms of extensibility?
As far as bounces go, it would probably be sufficient to have have a controller endpoint that we could post to via a web hook on a third party service, but as I'm still in the exploratory phases, I'm not 100% on what these email services offer. I do know that POP mailbox monitoring is not viable in our system, however, so whatever we choose, we have to investigate other methods.
I wasn't thinking of the RenderTasks pipeline when thinking of integrating a third party API, and that's a valid consideration. I like the extensibility of RenderTasks and I can imagine in many cases they can fill the gaps in functionality provided in many of the services' SMTP relay APIs.
To be honest, I don't really have a specific case in mind that requires a pluggable sender, I'm sort of thinking out loud and doing some explorations.
This is a simple POC on how you could use the current APIs to add a new bounce to the system. If you want to "disable" a bounced receiver this example requires that you are using the buildt in mailing lists but you might just change the code to disable the receiver is what ever store that you are using. The current provider interface does not support disabling using SubscribersProviders.
I see - it might not be a big task to open up something where you can create a bounce by your self and set a bounce type (ie. hard/soft). I would need to look closer at this but I'm 99% sure that it's an quite easy fix.
That sounds like it would be helpful. I know some services offer things like spam tracking as well. I'm not sure this would fall under bounce types or be its own thing?
It may be a few days before I am able to test this out, but I would certainly appreciate it!
Would you envision this would be a specific endpoint in the App_Plugins/NewsletterStudio path or an API call I can call from my own code? I can see use cases for both -- using webhooks to hit the endpoint or a scheduled task that pulls the events from whatever service and processes them.
I would suggest that we work togeheter on something that we can merge into the core of the package in the future - I'm thinking that a C# API would be good where you could just add your own bounces? Then If you want to do this using pulling or if you have a webhook on your providers side - that part would be for you to figure out?
Yes, that sounds like a good plan. An API for bounces (and bounce types) would be great help for us and I suspect a number of other users. I'm pretty busy the next week and have a vacation coming up, but I'll help in any way I can!
I've encountered another issue with the current sending service. I'm having trouble sending emails with my deployed dev environment. This environment is set to use Exchange with the IIS service account having "Send as" permissions on certainly Exchange mailboxes. The trouble is that these need to use the "UseDefaultCredentials" property but that's not exposed int the newsletterStudio.config.
I'm assuming Newsletter Studio is just using SmtpClient to send and this could, then, be exposed in the config file pretty easily. Unfortunately, I think this is preventing us from doing further testing with Newsletter Studio.
Options for sending newsletters
Hi Markus,
We're in the process of revamping how we provide newsletter services to our users and are currently evaluating Newsletter Studio. We're looking into integrating with a 3rd party mail service (eg SparkPost) to handle bounce / non-delivery etc.
While we can use a service as an SMTP relay, many services offer greater feature sets through their APIs. Is there a way to replace the default mailer in Newsletter Studio?
I did see that there are some events exposed, but it doesn't appear that those would quite fit the bill either.
Any suggestions / thoughts? Are there plans to open up the mailer portion such that customers could integrate with third party services a little tighter?
Thanks! Lucas
Hi Lucas!
Thanks for reaching out!
At the moment the bounce-features lives in it's "own area" of the package - we haven't been looking at how and if we could make this extensible but it might be possible.
We have looked at different ways to make the sending service pluggable - one challenge is that we have the concept of render tasks - each email is rendered in a unique process - before its send. Many of the APIs requires a template and then x numbers of merge fields in the payload when creating a send out. Since the render tasks are applied as a C# class that can do "what ever" with the content it's hard to fit without making some major braking changes.
Could you explain more about what would you need in terms of extensibility?
As far as bounces go, it would probably be sufficient to have have a controller endpoint that we could post to via a web hook on a third party service, but as I'm still in the exploratory phases, I'm not 100% on what these email services offer. I do know that POP mailbox monitoring is not viable in our system, however, so whatever we choose, we have to investigate other methods.
I wasn't thinking of the RenderTasks pipeline when thinking of integrating a third party API, and that's a valid consideration. I like the extensibility of RenderTasks and I can imagine in many cases they can fill the gaps in functionality provided in many of the services' SMTP relay APIs.
To be honest, I don't really have a specific case in mind that requires a pluggable sender, I'm sort of thinking out loud and doing some explorations.
Thanks for the reply, Lucas
Hi Lucas!
Have a look at this: https://github.com/enkelmedia/NewsletterStudioContrib/tree/master/Newsletter%20Studio%20V2/NewsletterStudioContrib/BounceManagement
This is a simple POC on how you could use the current APIs to add a new bounce to the system. If you want to "disable" a bounced receiver this example requires that you are using the buildt in mailing lists but you might just change the code to disable the receiver is what ever store that you are using. The current provider interface does not support disabling using SubscribersProviders.
Thanks for this. I'm out on vacation for the next week. I'll give a heads-up to my teammate in this and also take a look at it when I get back.
Lucas
Hi!
I see - it might not be a big task to open up something where you can create a bounce by your self and set a bounce type (ie. hard/soft). I would need to look closer at this but I'm 99% sure that it's an quite easy fix.
Let me know if you want something to test with?
/ m
Hi Markus,
That sounds like it would be helpful. I know some services offer things like spam tracking as well. I'm not sure this would fall under bounce types or be its own thing?
It may be a few days before I am able to test this out, but I would certainly appreciate it!
Would you envision this would be a specific endpoint in the App_Plugins/NewsletterStudio path or an API call I can call from my own code? I can see use cases for both -- using webhooks to hit the endpoint or a scheduled task that pulls the events from whatever service and processes them.
Thanks! Lucas
Hi!
I would suggest that we work togeheter on something that we can merge into the core of the package in the future - I'm thinking that a C# API would be good where you could just add your own bounces? Then If you want to do this using pulling or if you have a webhook on your providers side - that part would be for you to figure out?
// m
Yes, that sounds like a good plan. An API for bounces (and bounce types) would be great help for us and I suspect a number of other users. I'm pretty busy the next week and have a vacation coming up, but I'll help in any way I can!
Lucas
Hi Markus,
I've encountered another issue with the current sending service. I'm having trouble sending emails with my deployed dev environment. This environment is set to use Exchange with the IIS service account having "Send as" permissions on certainly Exchange mailboxes. The trouble is that these need to use the "UseDefaultCredentials" property but that's not exposed int the newsletterStudio.config.
I'm assuming Newsletter Studio is just using SmtpClient to send and this could, then, be exposed in the config file pretty easily. Unfortunately, I think this is preventing us from doing further testing with Newsletter Studio.
Am I missing something? Lucas
Hi!
I know there is room for improvements in the config for the smtp-servers. If you just leave this settings empty:
Newsletter Studio will fallback on the smtp-settings that you have set in the root web.config-file.
Give that a try and let me know =D
Yep, I had hit on that just after I posted. We can certainly test with this setup, and can probably run with this configuration as well.
We were initially thinking we required separate senders but probably don't really need to support that setup.
Thanks for the response! Lucas
is working on a reply...