(6.x-1.x) Comparison to Simplenews?

[Edited to reflect changes between version 1.0 and 1.1]

This was partially discussed in a now-closed issue, #668282: Different than SimpleNews?. I'll give a fuller treatment here. I'll try my best to be neutral, but keep in mind I may be a little biased :), so feel free to argue with or correct me here. If you haven't already, I encourage you to file a corresponding issue against the Simplenews module to get the other take on it.

The biggest difference is how they aggregate content. Simplenews uses the Taxonomy module, requiring someone to manually tag content for it to appear in the newsletter. SunMailer uses the Views module, associating each section with a node view used to automatically pull content. SunMailer has a cutoff date which will exclude older content, and this cutoff will be updated each time the newsletter is sent, so that the next newsletter has only new content.

Both SunMailer and Simplenews support scheduling the newsletter to be automatically sent. Since SunMailer also automatically aggregates content and removes sent content from future newsletters, its biggest advantage (IMHO) is that once configured and scheduled, it can run continuously without any user intervention.

SunMailer supports only one newsletter, but it can have multiple sections which users can individually subscribe to. Simplenews supports multiple newsletters, but each can have only one section.

Only authenticated users can subscribe in SunMailer; both anonymous and authenticated users can subscribe in Simplenews. I don't have any plans to allow anonymous users to subscribe because I rely on the Drupal registration process to verify that a user is who they say they are, but I have included a subscription block like Simplenews (but only for authenticated users, again), and I also allow users to subscribe when they register, though they won't receive any emails until they login once.

Both can support HTML and also SMTP w/ authentication, SSL, and TLS, but all this comes out-of-the box to SunMailer. (My personal take) I decided to use a third-party library called PHPMailer to accomplish all of this with ease, whereas with Simplenews you have to install and configure several other modules to get this, some of which have limited support.

There's probably some other things that only Simplenews supports (such as analytics), and it's been around a lot longer, but on the flip side it has become more and more difficult to maintain it (see http://groups.drupal.org/node/26531).

Looks lIke great module, judgIng by the descrIptIon provIded. I would only lIke for you to reconsIder the anonImous subscrIptIon. Anyway, best of luck In developIng It.

@encho
Can you clarify more on the rationale for anonymous users? I'm interested to hear the rationale for this.

While I'm going to do some work to make the unsubscribe scenario easier, sticking the subscription form on the registration page makes subscribing (almost) as easy as filling out a hand-built form for anonymous users.

It also keeps me from writing another layer to verify email addresses and changes to one's subscription. Likewise, the schema and database logic is much simpler when you're working with authenticated users.

My main concern about allowing anonymous users is that while it makes it a little easier for users to subscribe or unsubscribe (I'm not as worried about changing subscription options, since that's a less common scenario), it takes a lot of extra code to pull it off. This has major implications for both the stability and maintainability of the code base.

I can offer once scenario which makes anonymous users critical.

The company I work for ran a very simple newsletter for two years in our community, on a website that did not have any method of user registration. We collected a little over 3,000 subscribers.

When we made the switch to Drupal in October of 2009, it was critical that those users be migrated into the Simplenews tables seamlessly. We simply couldn't ask over 3,000 people to all register user accounts and re-subscribe. Even though these are people who receive our newsletter daily, the ratio of people that simply wouldn't have bothered to take these steps would have been killer.

We sell static advertising in our newsletter, so instantly we would lose so many registered users of our newsletter that we couldn't possibly meet the terms of our contractual commitments.

Even now, we have over 5,000 registered users on our site and 3,000+ newsletter subscribers, but only about 800 of those newsletter subscribers are also registered users in Drupal.

If the Simplenews module authenticated the newsletter subscribers against the users table, we'd be hosed.

The Sun also had many legacy users, and the way we handled it was to create a bunch of user accounts w/ a random password. It complicated the unsubscribe process a bit (though I'm not sure the old system had much an unsubscribe process to begin with), as these legacy users had to request a password to unsubscribe (though they could always email us if they wanted to unsubscribe, too). The one caveat is that we had to set login to a non-zero value in the database for all these users so that SunMailer would believe they all logged in once. (New users won't receive emails until they use the one-time login link.)

But I'm a bit hesitant to mark a legacy scenario as critical.

My approach for now is not to let anonymous users subscribe, but to come up with an alternative that is as close as possible. Let's look at three scenarios:

1. New user subscribes: You can subscribe on the registration form. The only difference between a hand-built form and a registration form is that you also need a username for the registration form. In both cases, you'll need to confirm you own the email account. The one-time login link you use for a registered Drupal account is not that much different than the custom verification logic provided by Simplenews.
2. User unsubscribes: In version 1.1, you have to login and then unsubscribe. In version 1.3, I'm going to add a new menu item where you just need to provide your username or email and your password, and you'll be unsubscribed. This page will directly be linked to from the newsletter. Once again, its not perfect, but still pretty close to perfect.
3. Change subscription options: You still have to login to do this, but this is a much more uncommon scenario.

I could see SunMailer maybe going in the anonymous user direction long-term, but like I said, it requires a lot of code and maintenence. The current solution is 90% as good, and there's a question of how far you want to go for that last 10%.

I too would like to have anonymous subscription. A sizable number of people (including me) are too lazy to sign up for a site just to get the newsletter. Anything that involves a password is a deal breaker. An email with an auto subscribe/unsubscribe link is acceptable. My site is small enough that I can handle unsubscribe manually by email.

A lot people are password phobic - too many in our lives as it is. No one wants to remember another one especially just to get a newsletter, and there's nothing more annoying than having to dig around for a password from a year ago when you want to unsubscribe. It's gotta be dumb-ass simple and fast or people won't bother.

Newsletters are often used as a form of advertising - in my case new or featured properties on a real estate site. These are transient users, and thus they have little patience to deal with signing up as a user.

It might be acceptable to require registration if it was a super simple pop up form for 'name' (not required) and 'email', but no password and no accessible account. There would be an unsubscribe link in a 2nd subscription confirmation email.

Not sure I understand why a lot of extra code is required. The user enters an email address in a block and gets a confirmation link by email which just adds it to the subscription list. Could you "borrow" some of the relevant code from Simplenews?

Interestingly enough, you never actually have to use a password to subscribe to SunMailer. After you fill out the registration form, which only requires a username in addition to your email and subscription settings, you will be emailed a one-time login link. Once you use this link, you'll start receiving email newsletters since you've logged in once.

Now to change your subscription settings or unsubscribe, you'll need to continue and set a password. I admit this isn't the ideal option, but it's not prohibitively bad. Furthermore, if you have permission to edit other user accounts, you can always unsubscribe someone if you receive an email request from them to do so.

Also, allowing anonymous users requires not only additional verification logic for anonymous users, but it also fundamentally alters the architecture, as SunMailer contains a heterogenous mix of subscribers w/ and w/o Drupal accounts. And of course, all this entails not just the one-time cost of building the architecture but the long-term cost of maintaining it, too.

Like I said, I'm more open on this in the long term, but there's a compelling argument that in the short term, I've come up with a good approximation of the ideal solution.

I agree, but the way SunMailer is built, it bcc's a batch of people on each email it sends. If I wanted to put in individualized unsubscribe links, I would have to send one email per person instead. That obviously will bring up some scalability issues and put a lot more stress on the mail server - I don't want to risk overloading the mail server just to make unsubscribing easier.

What about another option to unsubscribe by only filling in your email address and not a password? Since anyone could put in any email address into this form, I'd also have to send an email with a one-time unsubscribe link in order to verify that you own the email account you tried to unsubscribe. It's still a two-step process, but no password is required (but that option would still be available if you remembered your password).

Well it's the best I can do if I bcc the emails.

The Cornell Daily Sun used to attempt to one email per person, and frequently our mail server would die before it would finish sending the newsletter. I know of several other college newspapers that had similar issues, and a quick perusal of Simplenew's issue queue reveals many issues of the form "only some of the emails sent".

I know at one paper, someone managed to set up and configure a mail server himself which could handle the traffic, but how many people who use this module would have that much mail server expertise or the money to buy a dedicated mail server which could handle that load?

I'm aware of the spam issues w/ bcc, but the problem is 1 email/person often just doesn't work. And if it doesn't work, people don't use it, no matter how well designed it is.

This sounds pretty cool.

Quick question - so by "signing up" for the newsletter new users are also signed up for the rest of the site, correct (as they need to sign up with the site to get the newsletter)?

If so, this is actually a good way to build a community as the user will already be signed up for the rest of the site - and receive the e-mail. Plus, if they never want to sign into the site again, they still get the newsletter - right?

Seems like a good gimmick to me!

I run a real estate site where the users are transient - they're there only long enough to find a property.

So in that case I want to make their experience as painless as possible, and requiring them to join and sign in just to receive a monthly property newsletter doesn't cut it.

It's got to be really simple to subscribe and unsubscribe WITHOUT having to remember a user name and password, or they just won't bother.

In the web world we have visitors eyeballs for mere seconds, so we'd better make the best of it to retain them.

My understanding is they can just sign up once (with a user name, password and e-mail) and then receive the e-mail.

They don't have to bother signing in again - or even have to remember their user name or password.

I see what you are saying though with just using an e-mail address to sign up.

This will work for me as my users return daily. :)

So here's what I am thinking of for version 1.4:

1. If SunMailer sends an email to one recipient, it uses the To: field. If it sends an email to multiple recipients, it use the Bcc: field for obvious privacy reasons. You can opt to send individual emails instead of Bcc'ing batches of email addresses, but the default option is to bcc, and I've attached a warning about server load when sending individual emails.
2. When the individual mailing option is selected, I'm looking at ways to add a customized unsubscribe link to the email contents.
3. However, for both the individual and batch mailing options, I want some sort of password-less unsubscribe. Obviously the previous solution can only cover the former. Thus, I'll probably add an option to unsubscribe without a password, at which point a confirmation email would be sent to the email address (in case someone tries to unsubscribe an email address other than their own).

Item 1 is already checked in to the dev branch.

More Clicks to Escape an E-Mail List

By ALEX MINDLIN - NY Times

It takes more clicks to be removed from an e-mail list than it once did, the online marketing firm Responsys says. In a study of 100 large online retailers, the firm found that the proportion requiring three or more clicks to unsubscribe had grown more than fivefold since 2008. And the proportion letting users opt out with a single click shrank to 3 percent, from 9 percent, over that period.

Retailers hate losing subscribers, of course, as new ones are expensive to acquire. But they also have an incentive to let subscribers escape easily, because people frustrated with opting out typically hit the “report spam” button via their e-mail service. If that happens often enough, a retailer can be barred from lots of in-boxes, even those willing to receive its e-mail pitches.

Chad White, the research director for Responsys, said it was safest to let customers leave with two clicks or fewer. “Everything’s being measured against that one click on their report spam button,” he said.

http://www.nytimes.com/2010/03/29/business/29drill.html?ref=technology

So item 1 from #19 and #726948: Subscribe by user roles will be the major items going into the 1.4 release. (Does Simplenews have a role-subscribe feature?). For role-subscribe, the onus will be on the person using the module to ensure that a person can remove a role to unsubscribe from the sections that role is subscribed to.

Role-subscribe is turning out to be a pretty big feature, not just in terms of usefulness but also in terms of dev and test cost as well as code churn. I decided to move the items 2 and 3 in #19 to the next release and release 1.4 sooner than expected.

your list seems like good compromises - feature vs. expediency/legacy
btw, simplenews recommends that large mail lists should utilize a cron mailing 'throttle' that mails only 'n' newsletters per cron run
http://drupal.org/node/369754

thanks, Mike

With 6.x-1.6, you do not need a password to unsubscribe, and if your mail server can handle sending one email to each subscriber, this email will include a customized unsubscribe link. This will take you to a page where all you have to do is click a button to confirm your decision (standard practice for unsubscribing).

Since SunMailer is only for registered users, it also supports some nifty features: automatically subscribing users based on their roles, and sending each subscriber a personalized email.

The downside to this approach is that you have to register for an account to get the newsletter, but since the user registration form also doubles-up as the subscription form, the only difference is that you have to add in a username in additon to an email address.

However, 6.x-2.x is moving in a new direction, so I'll just add these closing thoughts and mark this as fixed.

I think the situation has evolved as the 2.0 branch of Sunmailer handles multiple newsletters and unregistered user subscription.

However, I am not sure this is true:
"Simplenews uses the Taxonomy module, requiring someone to manually tag content for it to appear in the newsletter"
For me, Simplenews does nothing to aggregate content unless you use the "content selection" addon. The later allows to select individual nodes manually and through Views. Simplenews requires a vocabulary to identify newsletter series, but it will not grab content based on taxonomy (apart everything that can be done with Views and the content selection addon) - at least, this is my understanding teaing around Simplenews.

I can confirm this. On it's own simplenews does not aggregate any content...Another "limitation" is that exclusively graphis in the body text are being encoded as mail attachments requiring a lot of work if you want to work with views and cck fields let alone node references, which I guess otherwise could serve as an easy means for content selection.