This is pretty big for us, too. The logic as it is now works well for a single tenant, but in a multi-tenant scenario, the inverse (what people are asking for here) is true.
"If you have multiple accounts using Sendy it turns out that it's very risky to use Amazon SES. I just had a long email conversation with Amazon about the multiple customers using my SES account and the main take-away was that they don't like it! They put me on probation after a long lecture about why having clients use my SES account sets off all sorts of "red flags"."
Seems like that is a major flaw with the Sendy product, at least for those wishing to manage the sending of emails from multiple client websites.
The home page does claim: "Optionally give your client access to their own brand and let them send newsletters on their own at a price you set." I note the singular 'client', not 'clients'.
No wonder the likes of cloudy.email, who use the Sendy product and have dressed it up as their own, require new clients (plural!) to go through the aggro of setting up their own AWS accounts.
dacumen also wrote" "I need the flexibility of determining which SMTP gateway to use so that I don't have to keep clients on different sub-domains or play traffic-cop and only allow one brand to send emails at a time."
Hold on... that last bit...are you saying that only one brand can send an email campaign at any one time? That too seems a flaw for a multiple-client user.
I have wondered why there have been fewer posts on this forum in recent years. I am beginning to understand why.
Agreed- having multiple brands/clients sending simultaneously is bad- from a single Sendy instance. As a matter of practice, ignoring the technical/timing difficulties, I'd only run multiple clients (where the client controls their own sends, lists, and practices) on a single instance (and single SES account) if I trusted these clients completely to the extent that "their downfall is my downfall" as far as SES is concerned (if you've ever dealt with trying to get delisted from a major blacklist you know what I'm talking about). I'd get them all their own Sendy instances and SES accounts, so that they'd manage their own sender reputation. If one of them decides to buy a list, or send emails 5 times a day, or send questionable content, or not handle bounces/complaints/unsubscribes properly, then it's on them. So I'd either want to completely manage it all myself (and then timing issues would work themselves out), or not at all. I would hope allowing multiple clients on a single SES account raises red flags for Amazon- there's a lot more risk, and, just like those other clients' reputations affects yours, yours affects Amazon's.
Back to your point- there's certain things Sendy excels at, but, yes, there's certain things it doesn't. It's a tool that serves a specific use case for specific users. I completely manage for multiple brands, some on SES and some not, and play traffic cop in the process.
If you want to use a mix of Amazon SES and third party SMTP for different brands, you’d need to use Amazon SES SMTP credentials in the brand settings instead of using Amazon SES IAM credentials in the main settings. Here’s where to obtain your Amazon SES SMTP credentials → http://docs.aws.amazon.com/ses/latest/DeveloperGuide/smtp-credentials.html
allowing to set a "usleep" OR "sleep" timeout PER SMTP would allow granular control and the option to to optimise sending over multiple SMTP staying within the limitations of each.
PS. I found most shared hosting and mass email services block connections to external SMTP, so the best way is to host sendy on your own server, or drop some $$ on specialised sendy hosting solutions: https://tjosm.com/5920/install-sendy-vps-virtualmin-nginx/
Let's upvote the individual SMTP throttle function?!
Comments
+1 for this feature
It seems normal that any local customisation (SMTP) should be checked first and global settings (AWS) are fallbacks for specialisations.
This is pretty big for us, too. The logic as it is now works well for a single tenant, but in a multi-tenant scenario, the inverse (what people are asking for here) is true.
dacumen wrote:
"If you have multiple accounts using Sendy it turns out that it's very risky to use Amazon SES. I just had a long email conversation with Amazon about the multiple customers using my SES account and the main take-away was that they don't like it! They put me on probation after a long lecture about why having clients use my SES account sets off all sorts of "red flags"."
Seems like that is a major flaw with the Sendy product, at least for those wishing to manage the sending of emails from multiple client websites.
The home page does claim: "Optionally give your client access to their own brand and let them send newsletters on their own at a price you set." I note the singular 'client', not 'clients'.
No wonder the likes of cloudy.email, who use the Sendy product and have dressed it up as their own, require new clients (plural!) to go through the aggro of setting up their own AWS accounts.
dacumen also wrote" "I need the flexibility of determining which SMTP gateway to use so that I don't have to keep clients on different sub-domains or play traffic-cop and only allow one brand to send emails at a time."
Hold on... that last bit...are you saying that only one brand can send an email campaign at any one time? That too seems a flaw for a multiple-client user.
I have wondered why there have been fewer posts on this forum in recent years. I am beginning to understand why.
Agreed- having multiple brands/clients sending simultaneously is bad- from a single Sendy instance. As a matter of practice, ignoring the technical/timing difficulties, I'd only run multiple clients (where the client controls their own sends, lists, and practices) on a single instance (and single SES account) if I trusted these clients completely to the extent that "their downfall is my downfall" as far as SES is concerned (if you've ever dealt with trying to get delisted from a major blacklist you know what I'm talking about). I'd get them all their own Sendy instances and SES accounts, so that they'd manage their own sender reputation. If one of them decides to buy a list, or send emails 5 times a day, or send questionable content, or not handle bounces/complaints/unsubscribes properly, then it's on them. So I'd either want to completely manage it all myself (and then timing issues would work themselves out), or not at all. I would hope allowing multiple clients on a single SES account raises red flags for Amazon- there's a lot more risk, and, just like those other clients' reputations affects yours, yours affects Amazon's.
Back to your point- there's certain things Sendy excels at, but, yes, there's certain things it doesn't. It's a tool that serves a specific use case for specific users. I completely manage for multiple brands, some on SES and some not, and play traffic cop in the process.
Hi texasjohn, all makes sense -- many thanks for confirming what I had suspected.
If you want to use a mix of Amazon SES and third party SMTP for different brands, you’d need to use Amazon SES SMTP credentials in the brand settings instead of using Amazon SES IAM credentials in the main settings. Here’s where to obtain your Amazon SES SMTP credentials → http://docs.aws.amazon.com/ses/latest/DeveloperGuide/smtp-credentials.html
Now the only thing missing is adding a way to throttle per smtp service. There is already a way to do this for sendy globally, as explained here:
https://sendy.co/forum/discussion/1272/how-to-send-only-500-mails-per-hour/p1
allowing to set a "usleep" OR "sleep" timeout PER SMTP would allow granular control and the option to to optimise sending over multiple SMTP staying within the limitations of each.
PS. I found most shared hosting and mass email services block connections to external SMTP, so the best way is to host sendy on your own server, or drop some $$ on specialised sendy hosting solutions: https://tjosm.com/5920/install-sendy-vps-virtualmin-nginx/
Let's upvote the individual SMTP throttle function?!
@ben, is this feasible?
This tread started in 2013 now its 2021 coming .....I dont think its happening
Some kind of update... even one saying "This isn't happening..." or "It's on the 2023 roadmap..." would be great.
There are a ton of us who want this capability, and now years later, getting an update doesn't seem like a big ask. :-\