PHPlist - running it from localhost with tracking via live website - newsletter

I've got a significantly large mailing list - 50K+ subscribers. To avoid stressing my servers, I would like to avoid sending emails through a components embedded on my website. Sending through here sends the CPU usage through the roof - so I'd like to be able to send emails locally. I can easily send emails through mandrillapp, so sending the emails out is not a problem. However, I've hit a bit of a snag.
Phplist seems to assume it is living on a public site, and inserts tracking info which routes the users to a phplist directory on my site (which obviously) does not exist.
Question 1: First of all, I'd like to avoid embedding this tracking - is this possible? Or else is there someway to include it and avoid the 404 error. Would I have to install phplist anyway on the server?
Question 2: I've already got acymailing to handle unsubscribes, so is it actually possible to keep this in place - just to make sure the acymailing is still my point of reference?
Question 3: How do people handle sending out large mailing lists? I know CampaignMonitor, MailChimp etc, but these get a bit expensive for my situation. I'd like to keep sending "internally" so to speak. Is there an elegant solution which will NOT kill my server but is not too expensive? I know I want to have the cake and eat, but it would be nice to hear what people out there are doing.
TIA
David

Related

Processing e-mail in Odoo 11 without previous threads – is this possible?

This Odoo company we're working with basically sends a lot of e-mail. One e-mail thread can turn into 100+ e-mails with different people brought into the conversation (CC'd) at different times. Due to the complexity of their e-mail management, they want to use their Gmail interface (Google Hosted) and CC an e-mail into odoo and they want it to get tracked in a thread. I've basically already done that... they have an e-mail like odoo+res.partner-432#domain.com (although it's hashed to not be easily readable) - they CC this and the full body thread gets included in chatter (mail.message) under respective model / id.
The challenge with this: the chatter messages can get huge very fast, due to their e-mail messages (because each e-mail includes main reply, and all previous history on thread). I've looked into some systems that have a "reply above this line" - and it just takes the latest message. And in those systems, eg. ticketing systems such as Zendesk, help scout, I believe the teams are using the ticketing system (not a gmail) and thus there is much more control over the inbox and incoming email (not to mention, those e-mails are usually 1-to-1, not including groups).
My questions:
Is there any other workaround that you see here to have odoo pull in only the last e-mail reply and not the full e-mail thread? I could probably build something like this: https://github.com/zapier/email-reply-parser - and hook it into odoos e-mail parsing, but that works on text format e-mails only (not HTML)... only. So it's not bulletproof, and I'm not sure it's worth it.
Even if this client DID use odoo 100%, I still don't think it would be possible to get it to work the way they want without major customizations (eg. Odoo's default behavior is to include all past e-mail threads)
I'm curious if anyone here see's any other solutions, otherwise – I doubt there is something here I haven't seen. :) (But very open to be proven incorrect!)

Is it possible to track emails to the extent that we get counts for "READ","DELETED","SOFT BOUNCE","HARD BOUNCE"?

The title being self explanatory, i would like to add some points to it.
1.Firstly, is it possible to track all these (READ,DELETED,SOFT BOUNCE,HARD BOUNCE) without using third party API?
2. If no, which third party services provide you the same ?
I am aware about the <img src="send-identifiers-to-this-url-to-track"/>, but this can only get me "No.of Reads/Forwards", but not deleted.
Anybody in for help ?
There are a number of things you can detect with your own software and no third party, though I don't know how they map onto the categories you list:
Tracking images and links, like you said (READ).
No mail server to take the message, e.g There might not be any MX record for the domain or your mailserver IP might be blocked by DNSBL (maybe what you mean by HARD BOUNCE?)
Mail server response codes. This might tell you for example:
Your email was rejected because the mailbox was over capacity etc (probably SOFT BOUNCE)
Rejected because it's spam (probably HARD BOUNCE)
Greylisted or something (probably SOFT BOUNCE)
There is basically nothing you can to detect the difference between unread and deleted messages though. That is also true of third party services. You will not even detect read messages unless your recipient turns on tracking images or clicks on a tracking link.
It's pretty hard to get this information, for instance I had to implement a postfix log analyzer that is mining the bounce information (soft/hard) and the reason why they occured and make it available via API in a structured form.

iphone : Is it legal to send an email from my app via an external server (with a PHP script)

i wonder what is the best solution to send an email from my app.
I have two solutions :
1- using MFMailComposeViewController :
it works well. Easy to use. but use an huge amount of RAM : in activity monitor, when i use this, the RAM allocation grows from ~10 Mo to ~20Mo, and is never freed
2- Setup a PHP-Script that handles sending email.
it works very well too. And it uses very few RAM : around ~3 Mo with this solution.
So, my question is :
does this is allowed by apple ?
Does anyone is using this solution in his app ?
I'm pretty sure apple doesn't care how some email gets sent out when people use your app.
The more important issue is that when sending from the device, using MFMailComposeViewController, you get the following for free:
users see a familiar interface
users send their mail from their own account
users have messages in their sent folder
users can choose to archive a message
Using your own php script, you get:
a lot of extra work to do, and stuff to maintain
either A) always the same sender address (from your script), or B) an address that the user must type in (afaik there is no legal way to get an email address from iOS)
in case B), trying to send on behalf of the user, you will run into spam filters quickly (think about SPF and such)
Looking at these things, the proposed solutions are really not comparable. So the real question is, what kind of email is sent out. Is it feedback sent to you, or is it mail sent on behalf of the user?
The memory concerns are new to me, I never experienced such problems. Do you handle memory management the proper way? If so, there is nothing to worry about. Don't focus too much on the "activity monitor" if you're not actually experiencing problems.
I'll throw in a third alternative here. If you want to leverage a web service for emailing you could leverage an existing email service such as PostageApp (http://postageapp.com/). They have a a library you can use as part of your iOS / Mac app that interfaces with the API which allows you to send email from Objective-C. You can check out the plugin here:
http://dev.postageapp.com/pages/plugins.html. The nice thing about leveraging a service like this is you don't have to worry about the internals of sending email and lets you focus on your application.
(Disclosure: I work for PostageApp and built the plugin)

Email to rss on server

for my group at the university I'd like to set up a server-sided email-to-rss service.
It should work like that, that different people can send emails to a certain address (nothing proprietary like gmail but a certain imap or pop server) which will the be translated into an rss feed. One main and important feature has to be that one can see the sender of the email in the feed. Furthermore it would be nice (to take the load off the server) if the emails get translated to a feed only once a day or so.
Does anyone has some input on this subject? Are there any scripts/services which will allow that?
Thanks a bunch.
Instead of "reinventing the wheel", you could use a mailing list that supports RSS. Your people can then write the mails to the mailing list and you can then use the mailing list's RSS feed however you intend to.
This should help you find a solution: https://encrypted.google.com/search?q=mailing%20list%20rss
Pick a programming language you're familiar with, then use either an imap library to fetch the E-mails (through cron, every hour or something like that), or if you have access to procmail on your mail server, launch your script as an email arrives (this shouldn't be too much work to handle for a server, unless you're talking a vast amount of E-mail).
The script would just insert the E-mails into a database, before extracting them and outputting the RSS-feed directly from that (this shouldn't be more than a handful of lines of code).
There's a couple of providers that does this for you, although it seems that the most popular ones have disappeared. Advanced Email2RSS seems to be an option, although I have no idea how good they are or if it'll even solve your issue.

How To Test Email Deliverability - % In Junk Folder

Does anyone know a good tool to test whether your emails are going into spam folders?
My web app generates emails to users, and I've been getting a lot of reports back from people saying "hey, no one ever responded to my message".
I have SPF rules in place and functioning correctly (email header shows an spf pass). I've also run my message through spam assassin and it scores very low.
Any other ideas?
To know if your email goes in the inbox, you need to get a metric called "Inbox Placement Rate". This indicator can be provided by Return Path, but it's quite expensive. If you're not sending huge volumes it might not worth it. The only way to measure the IPR is actually to have a certain number of test inboxes... In other words: the only way to chech that your email is not in the spam folder is to make the test and see what happen. There is not other magic solution and that's what Return Path is doing.
This means that when you hear about people claiming they have a 99% deliverability / delivery, it might be true be it just means that the email was "accepted" or "delivered" by the ISP. It's a lot, but it's not everything!
What you should do is the following: use an ESP focusing on deliverability. Personally I work for Mailjet. I believe it's the best value you can get: personalized DKIM and SPF are provided for free, you get the antispam scorings, the analytics, Ip reputation monitoring, throttling, etc. It's an all in one tool to avoid the headaches of optimizing yourself. It's more expensive that Amazon SES because you get a lot of added value services, but it has much lower prices than a lot of traditional ESPs!
Bottom line is: optimizing everything yourself is a full time job. Knowing exactly if an email is in the inbox or not will cost you a lot. The best way to proceed is to:
respect the best practices (opt in, not too much images, no red, etc.)
get some metrics such as open rates, click rates, delivery, etc. and watch their evolution over time. Any change from one sending to the other might be a signal for a problem you want to investigate.
Use a tool that takes care all the deliverability optimizations
Mailjet is cool because no matter which plan you pick, you get to use all the options. But if you want a full overview of what is existing, check out this comparison table:
http://socialcompare.com/en/comparison/transactional-emailing-providers-mailjet-sendgrid-critsend
If you're a perfectionist who wants to finetune the layout, how the emails are displayed etc. Check out Litmus, it's also a quite powerful tool!
http://litmus.com/
Simple answer: Use Mailgun!!!!
http://mailgun.net/
They will do all of your email deliverability and setup for you and give you a powerful API to build on! They are amazing. You'll never have to worry about domain keys or SPAM filtering again!
You should also check that your IP is not on any of major blacklists. dnsbl.info
This will at least give you an idea if you actually are getting flagged as spam.
For the past two years, we've used the service DeliveryMonitor.com. However, they've stopped accepting new applications which is a big red flag...
I'm currently evaluating the service from emailreach.com using their free trial
... We are now using DeliveryWatch.com with pertty good results thus far...