This is definitely a *must* for anyone serious about long term viability of email for their business.
The MTA is that part of your Linux server that actually sends the mail. arpReach hands off the messages to the MTA and that's what actually sends it. Most Linux servers ship with Sendmail for free, but your sysadmin can install others.
If you don't know what MTA your server is using... it's probably sendmail.
Here are a couple of helpful links for more info:
Sendmail
http://en.wikipedia.org/wiki/Sendmail
MTA
http://en.wikipedia.org/wiki/Mail_transfer_agent
Is the GreenArrowMTA something like a replacement for using Amazon SES or Sendgrid? Or does it just partially handle the deliverability issues?
Thanks so much for taking the time to post all of this info and answer questions.
Roger
I haven't heard anything yet...
Hi
Just wanted to say that I'd still like to have the feature. No doubt Tim is right about where the operation should reside but my personal view is that I'd still like it in the software. It's something Interspire seem to have which was one of the reasons I shortlisted them for a project recently. Also HitDirector, who Michel recommended for arpR hosting, seem to offer a service too, so it's reassuring that they will handle it as part of the hosting package.
I'm interested to learn more about Green Arrow but they don't seem to have any pricing info on their site..?
Many thanks
Debra
Tim Bratton
I've heard rumor that this will be supported in an upcoming release.
I'm so excited!!!
We currently process the FBLs manually and keep statistics about what emails are generating the spam complaints.
After you handle the basic "infrastructure" issues such as DKIM, SPF, FCrDNS, Domain Keys, etc. and monitoring and staying off black lists, FBL's are the MOST critical thing to keep your deliverability up.
In addition to the basic removal of the complainers from the list, I would like to see statistics.
The most important are:
#1. Which email generated the complaint. Was it a broadcast or an AR?
=> This is important so you know immediately if some subject lines are causing problems. Sometimes you think you have a "winning" subject line.. but in fact it is crippling your business because people are opening the email and then too many are clicking "SPAM" and then your deliverability goes to ZERO with that ISP.
#2. What AR was the customer subscribed to?
==> This is important because it can help you find if you are being too aggressive about looping or flowing people into new ARs, or help you decide when you might need to do double opt in vs. single opt in
#3. What email service. Was the spam complaint generated by a user with a hotmail, yahoo, comcast, live, etc. account?
====> This is important so that you can look for issues at any particular ISP.
#4. When did the user sign up?
====> This is important so you can see if any trends are developing. Are you doing something to upset long time subscribers... or is primarily newer ones who are complaining?
We'd also like a log so that we can verify that the complainers are being removed correctly. I think this is especially important in the first rev of the new FBL processing feature.
Of course there is a lot more important data that can be useful, but these are pieces of data that we've found to be particularly helpful.
12 people like this idea