Deliverability is very important when it comes to sending out email newsletters from Nourish. Open rates and click-through rates don’t mean a thing if nobody receives your newsletter in the first place.

There is something quick and simple you can do on your end to instantly decrease the likelihood that your email will arrive to your recipient as SPAM . You can setup an SPF Record on any domain you use to send email from, and allow our server smtp1.nouri.sh.

Without getting into all the technical details, you’re basically telling the rest of the Internet that it’s okay for email from your domain to be sent out by our servers.

I quick wizard can be found here. If you have any questions, don’t hesitate to ask.

UPDATE :
we altered the headers in the mailings we send, and there’s now no need for you to add your own SPF records. Mail servers will now just look to make sure that the mail is sent via nouri.sh, and SPF and DomainKeys will always pass.

• 3 Comments

Listen live on Wednesday December 19th at 10am (PST) to wsRadio.com to hear Chris and I interviewed about Nourish on the RSS Ray program, a segment led by Brian Offenberger. RSS Ray reaches over 2 million listeners focused on learning more about RSS . If you can’t tune in for the live show, we will post links to the podcast on our blog.

• 0 Comments

This year, Matt and I have decided to attend SEED Conference. We’ve heard good things about last year’s conference, and are expecting a treat this year as well. Let us know if you’ll be attending as well. We love hanging out with customers, partners, colleagues, and really anyone who will have a beer with us!

• 1 Comment

I’ve used Xen a lot in the past, and I really like it. It’s about as close as you can come to having a pseudo-dedicated server: your own kernel, complete isolation, guaranteed non over-committed resources. And, it’s probably the best choice if you’re running an unmanaged hosting environment full of strangers. At Integral Impressions we evaluated both Xen and OpenVZ for our managed hosting solution. Hands down, OpenVZ made the most sense for us. Here’s a few reasons why:

• Negligible overhead. All OpenVZ virtual servers share the same kernel. This makes for such little overhead that it goes unnoticed.
• Flexible resource allocation. We can share resources among our virtual servers much more flexibly than we could with Xen. For example, our Level 3 hosting plan has 1GB RAM . But we don’t really cap it at 1GB, that’s just what we guarantee. In reality, we’re fine with a customer’s virtual server temporarily using more than that. If it becomes permanent, we’ll just ask them to upgrade. Our servers have a ton of RAM , and there’s always GBs to spare, so no sense in letting them go to waste. If we were using Xen, we’d have to cap the customer at 1GB and they’d need to upgrade to increase that, even if only temporarily. The same deal applies to CPU and disk space.
• Extremely quick upgrades and downgrades. We can upgrade or downgrade a customer’s resources in a matter of seconds and usually with zero downtime. How’s that for cool. Even disk quota’s can be altered in seconds – something that’s usually a painful operation with Xen.
• Stability. OpenVZ is the core of a commercial product, Virtuozzo. Virtuozzo has been through several years of production usage, and it’s rock-solid. We’ve not had a single problem with OpenVZ. What’s more, should we ever need commercial support we can always contact Virtuozzo.
• Performance. I can’t provide you with any benchmarks right now, but compared to some of the Xen solutions we’ve used in the past, OpenVZ seems a lot faster. Read into that what you will, but that’s our experience.

If you’ve also used both OpenVZ and Xen, I’d love to hear your experiences. What made the most sense for you? Why?

• 0 Comments

Some time ago we implemented a basic spam filter for Ticketish. Nevertheless, those pesky spammers continued to push through their mail. No more. We’ve implemented a full-blown bayesian spam filter for all Ticketish accounts. If you’ve never heard of bayesian filtering, a great place to start is Paul Graham’s article A Plan for Spam.

To get the most out of the filter you need to train it. When using Ticketish, you’ll see some new items in the drop-down for managing multiple tickets: Spam and Train Not Spam. Start by selecting a whole group of tickets that aren’t spam, and train them so. Then, make sure you mark all spam tickets as spam instead of just deleting them. Over time, Ticketish will become very accurate at determining what’s spam and what’s ham.

Every Ticketish account is trained separately. This is important because what’s spam for some might be ham for others. All accounts start with a clean slate, so it’s up to you to train appropriately. We’ve developed the spam filter as a RES Tful web service, so expect to see it pop up in our other applications as well.

• 0 Comments