[unisog] off topic: mass emailing
feenberg at nber.org
Fri Sep 17 12:15:59 GMT 2010
On Thu, 16 Sep 2010, Rick Hayter wrote:
> Sorry for the off topic post, but I'm looking for some feedback about
> how you are handling requests for mass mailings to internal
> We get requests for a list of students, or only undergraduate
> students, or only sophmores, or faculty, or only adjunct faculty, or
> only full time staff, or full time staff minus the people who attended
> function X, etc. It's driving us nuts. We've setup some common lists
> on our mail server and that handles a lot of it, but sometimes they
> want to use a program that's hosted outside that allows them to tailor
> the message to different groups, or to create "fancy" content that
> doesn't translate well when sent through the list (for some reason...)
> Has anyone found a way to handle these kinds of requests? I can't
> always say no (sometimes it comes from a VP or the Pres), but because
> it's happening more often it's starting to impact our productivity -
> someone has to be pulled off of another project to interface with the
> requestor, find out what they need, generate an email list, etc.
> Is there a software package that allows users to make their own
> request for this data (we're a Banner school)? Is there an outsourced
> solution? If so, how do you keep the addresses up to date and
> "categorized" correctly?
> Any pointers (or even sympathy) would be appreciated!
We do so much of this that it seemed worthwhile to create an interface
from the mail system to our database. There is some documentation here:
but briefly, the idea is that the sender can place a suitably mangled SQL
statement after the plus sign in a mail message addressed to user
"db-mail" which will specify what users are to receive the message. Of
course, you would have to moderate the result, but that isn't too hard.
No doubt few of your users could write their own SQL, but as requests came
in, you could create a resuable alias for each one, which would cut down
on the work for repeat reqests, since the database would always be up to
date and the alias would still be there.
> Rick Hayter, Director of Administrative Computing
> University of Dallas, 1845 E. Northgate, Irving, TX 75062
> 972-721-5227, <public key: rhayter at acm.org at pgp.mit.edu>
> unisog mailing list
> unisog at lists.dshield.org
More information about the unisog