http://qs1969.pair.com?node_id=699493

SouthFulcrum has asked for the wisdom of the Perl Monks concerning the following question:

I’m looking for ethics suggestions and an answer to a Perl question.

I’m developing a Web-based CMS for non-profits using Catalyst. Non-profits really like e-newsletters. I’ve developed an integrated e-newsletter app, but I don’t want to allow users to implement it before I’ve made good faith efforts to ensure they can’t add people w/o subscriber confirmation.

Currently, here’s what I got:
An individual can visit a site and “Subscribe” or “Unsubscribe” via a one-field form.

If a visitor chooses to subscribe, s/he will receive a message saying “subscription req...to receive... was sent from IP....on date...link to confirm...sorry if you didn’t make this req, just do nothing.”

A visitor who chooses to “Unsubscribe” will receive a confirmation message; former subscriber does not have to do anything.

Requested from IP, request date/time, confirm date/time and unsubscribe date/time are all recorded in the database.

For actual sending, the app makes proper queries to generate a list of currently confirmed subscribers. And, of course, there would be a proper footer about how to unsubscribe.

Should I retain anything else?

A site owner can add subscribers through the site’s backend administration app. Each subscriber, by default, will get the same confirmation message described above. The user who invited the person will be recorded in the database, as well as “date_invited” and “ip_invited_from”.

Currently, I’m considering whether to allow site owners to invite people w/o sending a confirmation message. It would use some JavaScript warnings to stress the point that s/he should generally avoid it, and force the user to state why a confirmation message isn’t needed, such as when migrating a previously established list, like Yahoo! Groups, Mailman, etc. The reason would be logged in the database. Again, should I retain anything else here? Or is this just a bad idea?

Finally, a Perl-specific question: any suggestions on how to parse a mail log (Postfix, in particular) to show if messages are bouncing, and why? I just don’t feel good about directing people though a script to show that s/he looked at the newsletter. I’m thinking that Mail::Procmail is looking good. I assume Parse::Syslog::Mail is good, but the docs seem to be sparse.

Replies are listed 'Best First'.
Re: Bulkmail Ethics/Parsing Mail Logs
by Corion (Patriarch) on Jul 23, 2008 at 06:31 UTC

    Your users will find and use any way to add people without having them subscribed. Especially because non-profits are driven by a Greater Good and the workers for that nonprofit actually believe in their plight. They'll believe they are helping those who they are spamming.

    In short, any measure you create to "add people" without them confirming will just end up in being used, together with a dummy reason, to add people without their consent.

    On the technical side of things, have your script add a Bounces-To header, which lists the email to which the bounce should go. Having a custom Bounces-To header for each recipient and a custom script that gets called by Procmail for all bounces means you can update the status of your recipients as the bounces come in.

      I've never heard of the Bounces-To header, and googling for it reveals precious little. I see that Amazon uses it, but there doesn't seem to be an RFC which mentions it. There isn't even a wikipedia article about it, and it is not mentioned in their article on Bounce message. Are you sure that it is widely supported?

      The way I know to handle this is to set the Return-Path to your bounce address, and the From header to the value that you want the user to see. For instance:

      Return-Path: user_123@bounces.domain.com From: help@domain.com

      Update: Of course, you would also need to process the bounce messages correctly, distinguishing temporary from permanent failures. There is the module Mail::DeliveryStatus::BounceParser but I've never used it and have no idea how effective it is.

Re: Bulkmail Ethics/Parsing Mail Logs
by massa (Hermit) on Jul 23, 2008 at 09:47 UTC
    Bulkmail ethics is somewhat simple, and I'll resume it for you in the following rules:

    1. don't

    Yeah, that's it. E-mail and telephone are for _personal_ or _work_ communication, about _personal_ or recipient-work-related issues, and even so limited ones (you want to reset your password? when can you come to the branch to talk about your debt? can you go to Satriani's show August 1st -- may I try to get some courtesy tickets? how is the problem in module CI027 progressing?)
    Anything other than that should be handled by specific mail lists, newsgroups or (preferably!!) RSS feeds.
    []s, HTH, Massa (κς,πμ,πλ)
Re: Bulkmail Ethics/Parsing Mail Logs
by philcrow (Priest) on Jul 23, 2008 at 13:15 UTC
    I'll be a contrarian here. If I give to a charity and they have any way to get my email address, I expect to get their newsletter. This is not really spam, I contacted them. The key is the opt out, not the opt in.

    Remember, charities have a brand to defend. While they are willing to spam to a degree, they don't want people angry at them. It is in their interest to limit the mailings and they generally know this.

    The only caveat is that the charity should not exchange lists with other charities or buy names. If they do, don't let them have your product (if that's possible). Opt out is most vital then.

    Phil

    The Gantry Web Framework Book is now available.