SES on 1 brand, SMTP on another
I've been running with a single brand and sending via SES. I want to send via another delivery provider (over SMTP) on a separate brand. There are no external clients- I'm controlling both brands, but setting them up separately so that I can use different providers. When setting up the second brand, I entered the SMTP settings of the other provider (SendGrid). When I go to send via SendGrid on the second brand, however, it's still sending via SES. Is it possible to have this configuration, without removing SES credentials (and having to add them back later when I want to send from the first brand via SES)?
Thanks!
Comments
Good question, I need it too.
Hi @texasjohn,
When you send an email, Sendy checks if AWS credentials are set. If they are set, it'll send via SES. Otherwise it'll fallback to using your SMTP settings if they're set. If SMTP aren't set, it'll fallback to using PHP's sendmail.
You can't set one brand to send via SES and another to send via SMTP at this time. I'll move this to suggestions for future consideration.
Thanks.
Ben
Ben- thanks for the prompt reply- appreciate the help as always
@texasjohn - You're welcome.
Just wanted to add my vote to this. Would be good if SES could be the fallback for all clients without an SMTP set, and use SES if it doesn't have any. Actually, it would be great to be able to set this on a brand-by-brand basis and set a global setting for brands where we didn't specify any preference.
One more vote -- brand by brand choice of SES or SMTP would be awesome
Vote for this
Vote for this
I need it to!
I would also like to be able to use amazon ses as standard and create a new brand and use another smtp like mandrill instead.
Vote for this!
+1
+1
I need this feature too.
everyone need this !
lets go Sendy... lets go Ben ! 
Need this feature too. More than a year from original post. Any news on when you'll be able to make it happen? Thanks! Keep up the good (great!) work.
Presently the only workaround till Ben updates Sendy is a second installation of Sendy on the same domain or sub domain.
I got my Main install on Amazon SES, on a subdomain SendGrid, another subdomain for a friend that I put in a separate SendGrid.
Sendy's license allows unlimited installs on your domain..
+1
I need this feature too.
Has there been any movement on this feature request? I would find this very valuable as well.
The workaround I've been using for quite some time, is to set up 2 one-liner mysql commands as aliases- one being my "send through SES" command which sets s3_key and s3_secret in the login table, and the other for sending via SMTP that clears the two columns, and I just urn one or the other depending on where I want to send from. Obviously can only send through one brand at a time, but it beats having to set and clear those fields in the UI.
Definitely needed. Any news about this? I
I am using SMTP, is it possible to keep using different SMTP for each brands? Thanks
+1 Here. Yea, this is a big deal. I have several clients using my Sendy installation and I don't want all of them on my Amazon SES account. One in particular is a little sloppy with their email lists and got me put on probation with Amazon because their bounce rates were too high. Another is a high value client who I want to send through my DYN SMTP account for higher deliverability. 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.
I get why Sendy is so closely tied to SES (duh) but the inability to leverage backup SMTP servers is a serious scaleability issue.
+1
Solved.
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".
Solutions - dump Amazon SES in favor of Mandrill! Mandrill gives superior service, superior reporting, and the same level of integration with Sendy as Amazon SES and the kicker is because you're not locking your Sendy account with SES credentials, you are free to mix it up a little! I now have my big clients on Dyn, my normal clients on Mandrill, and my personal account on my SES account to save a few pennies.
Much better and more reliable solution than using SES alone.
dacumen - you say that this is solved. But is solved only as long as we give up Amazon SES.
This feature would be really nice.
@texasjohn: would you mind sharing those statements? Of course I don't need your SES creds
This topic was started in 2013. Would it help if people would chip in to get this functionality implemented, @Ben? After all, if I use my own time that costs me too.
The SES credentials are set at the instance level, and the SMTP credentials are set at the app level. I always have my SMTP credentials set, and, knowing that, if the SES credentials are set, they'll take priority, and if not, Sendy will fall back to SMTP.
I have these 2 lines set up as command aliases (substitute in "user" (sql user, not app user), "dbname", "s3key", and "s3secret"- also make sure login record with id=1 is the one you want). It will also prompt for your sql login.
alias do_ses='mysql -u user -p -e "update login set s3_key='\''s3key'\'', s3_secret='\''s3secret'\'' where id="1";" dbname'
alias do_smtp='mysql -u user -p -e "update login set s3_key='\'''\'', s3_secret='\'''\'' where id="1";" dbname'
There's a lot of quoting and escaping in there to allow the SQL statement within a quoted command script to work.
When you want to use SES, run do_ses; run do_smtp when you want to use SMTP. All this does is populate or empty SES credentials a little easier and quicker. You could do that by hand in Sendy with the same result and a lot less risk.
Yes it's dangerous to have S3 keys in a plain-text script. Yes if Ben changes Sendy SES/SMTP fallback functionality at any point this will break, and it will also break if the data model changes. If you're not comfortable with SQL and Unix command line, don't do this. This isn't an improvement on Sendy app functionality, it's just a data hack.
I also vote for this! Being able to set individual Amazon SES and also SMTP servers, individualy on each client is a must!
It is actually really a simple piece of code.
I did it in my copy.
But the problem is that I have to rewrite it again for each version update.
If @Ben could do this in his next version, it would be really great.
For example,
the code in includes\create\send-now.php
is given as
if(get_app_info('s3_key')!='' && get_app_info('s3_secret')!=''){Code to send email via SES}else if($smtp_host!='' && $smtp_port!='' && $smtp_username!='' && $smtp_password!=''){Code to send email via SMTP}All we have to do is interchange the condition as
if($smtp_host!='' && $smtp_port!='' && $smtp_username!='' && $smtp_password!=''){Code to send email via SMTP}else if(get_app_info('s3_key')!='' && get_app_info('s3_secret')!=''){Code to send email via SES}If a brand has SMTP details set in it, then that configuration would take precedence over sending via SES.
If you want to use SES, then remove the SMTP details from the brand.
This has to be done wherever the email sending code is present.
Example: includes\create\test-send.php
@Ben, any update on this issue?