Hopefully this is a simple yes/no question 
If I were to download the latest PHPList version plus the Amazon SES plugin, and sort out an Amazon SES account, should it work all right? I just wanted to check the plugin is still up to date. Thanks.
@Jonathan11 Yes that should be ok.
1 Like
Why do you need a plugin for using Amazon SES can´t you configure SMTP credentials in the config.php file?
The amazon ses plugin support ‘multi-curl’, which sends faster.
Sorry to resurrect this. I toyed with the idea of moving to Sendy because of its SES integration, but I think I prefer PHPList. I need to move to a new server anyway, and start using a service like SES.
Is the current recommendation still to use PHPList (now 3.6.16) with the Amazon SES plugin? (Edit: just noticed that the latest stable release is 3.6.15.)
Also, what the URL for that plugin? I’m coming across some broken links.
Thank you.
@Jonathan11 The plugin’s GitHub repository is at GitHub - bramley/phplist-plugin-amazonses: Plugin for phplist to send email through Amazon SES
You can see a Wayback Machine archive of the phplist documentation site at start [phpList Resources]
Thank you.
I’ll read the instructions on the Internet Archive at plugin:amazonses [phpList Resources].
What happened to the resources subdomain? (Edit: I see you are in the dark too: 🚨 resources.phplist.com seems offline - #4 by duncanc).
How does PHPList with your plugin deal with Amazon SES, for example if SES says there’s a hard bounce, soft bounce, complaint, etc?
Also, I imagine there’s setting for rate limits. PHPList just worked when I installed it many years ago, but I imagine that SES will be fussy about this.
I don’t think the sending plugin affects bounces, although I can’t say that authoritatively. I am happily using the SES plugin. All of my bounces - whether from SES blocking something on send, SES getting an “abuse” report, or another system reporting a failed delivery - are delivered into a mailbox that phpList polls for bounce processing. I am very glad for SES having its own do-not-send list (which I can add to if needed), as that has kept me safe when phpList did not. I would not currently want to use phpList without also using the SES plugin.
1 Like
The plugin itself doesn’t deal with this. You need to enable “Email feedback forwarding” for your domain’s Identity in the Amazon SES Configuration page. The SES developer guide has documenation on most of the things that you are asking What is Amazon SES? - Amazon Simple Email Service
1 Like
I’ll read this. Thank you both. I guess sometimes phpList will try to send to email addresses that SES has blacklisted. Is that rare or common, and does Amazon mark you down when it happens?
I’m not 100% certain, but I’m pretty sure Amazon does not ding you for trying to send to an address that is already in your own suppression list on SES. If it’s an address they suppress globally but isn’t in your own suppression list, that might count against you, I’m not sure.
I just keep a casual eye on my reputation on SES and know it’ll never be perfect, because people will mark things as spam even after completing a double-opt-in onboarding - just being lazy, malicious, forgetful, or whatever. I’ve never come close to getting a warning, and hopefully I can continue avoiding that.
It would be great if phpList or the plugin could update my SES suppression list when a subscriber unsubscribes, but for now it’s good enough for me that SES automatically adds spam complainers to my suppression list. It’s not a comprehensive solution, but it addresses the worst pain point.
Thanks for the reply. I think the closer integration with Amazon SES is probably Sendy’s main selling point – from my understanding, as soon as a “complaint” or “bounce” email is received, Sendy gets that from SES and automatically marks the email address as spam/complained or bounced accordingly. There seems to be a 1:1 relationship between Sendy and SES.
Sendy isn’t doing anything that phpList can’t do. I don’t think it’s more closely integrated. The only issue for us is figuring out how to get phpList to do what we expect.
Neither phpList (with the SES plugin) nor Sendy is directly controlling SES beyond sending. They are not updating a SES user’s suppression list. AFAIK, they both have “local” suppression lists instead (however they may be named and handled - I find phpList frustratingly confusing in this respect), so anything on the AWS/SES side is “secondary” - and fed new addresses via AWS itself - while being fundamentally more important. Go figure.
Anyway, Sendy itself is “off-topic” here - but feel free to reach out individually if you want to discuss further separately.
Thanks. I am 99% sure that Sendy takes the “hard bounce” or “complaint/spam” signal from SES and immediately blacklists the email address. I don’t think phpList differentiates between these and “soft bounce” (mailbox full etc) so it would just increment the bounce score. However, there are a couple of things that Sendy doesn’t do (preferences page and unsubscribe reason) that make me want to stick with phpList.
Bounce rules in phpList should allow you to detect complaint/spam messages and blacklist those addresses, to ensure those messages aren’t treated as regular bounces. In theory.
I use the SES plugin and have bounces forwarded to an inbox that is polled every 15 minutes. I have a rule for messages from the complaints@ address at SES, which triggers an action. Detection is the easy part, though. But what action should be taken?
Everything seemed to be working fine. Now everything seems broken and getting worse. Just a few minutes ago, I realized that my server has been reprocessing a complaint bounce every 15 minutes, and I have no idea how long this has been going on. Probably for days, since the bounce was received. The action I have set for that rule is “blacklist email address”. My “Subscriber history” shows two entries every 15 minutes: auto unsubscribed, and added to blacklist.
In general, and applicable for proper handling of complaints, I think phpList is burdened by confusing design decisions and inadequate documentation. People don’t subscribe to lists, they subscribe to subscribe pages (transaction messages are defined for subscribe pages, not lists). A subscriber is different from an email address (you can blacklist a subscriber or you can blacklist an email address). You… should? shouldn’t? …delete bounces. (When I switched from keeping them all to deleting them is when my troubles started, btw.)
I have experience using MailChimp and MailerLite, and this confusion was never an issue with those services. There was no disconnect between “subscriber” and “email address” - a subscriber had an email address, a 1:1 relationship, which is the normal scenario. (I realize there are other cases - much too rarely to affect design, IMHO.) Transactional emails were defined per list, not by the particular form someone used to subscribe to a list. And so on.
Anyway, getting back on topic, if you use the SES plugin and you have bounces directed into a mailbox checked periodically, you “should” be able to easily detect which ones are complaints to handle differently.
1 Like