is there a way to keep the real name w/ the e-mail address upon subscription? has anybody patched or knows of some patches that will allow this? tia, Bill
On Tue, Jul 30, 2002 at 01:43:29PM -0700, William Ahern wrote:
is there a way to keep the real name w/ the e-mail address upon subscription? has anybody patched or knows of some patches that will allow this?
I've wondered, if the addresses are properly formatted with RFC822 comments, will they be handled correctly at distribution time? Seems like a reasonable assumption, and it would be very nice indeed to have those real names handy. But it's never gotten to the top of my priorities to poke through the code, or try a test case on my list. Maybe one of the experts can say for sure one way or the other. Jim
At 1:26 PM -0400 7/31/02, Jim Osborn is rumored to have typed:
I've wondered, if the addresses are properly formatted with RFC822 comments, will they be handled correctly at distribution time? <snip> Maybe one of the experts can say for sure one way or the other.
(*sigh*) At the risk of yet again upsetting Ms. Judge's delicate constitution by pointing out the painfully obvious in my finely-honed, highly ascerbic fashion, please read the Manual file which comes with the SmartList distribution, specifically section 5. Of course, you'll need to write your own routines if you want to retain this information at subscription time (I suppose there is some sensible reason for a mailing list server to retain human names, but it escapes me at the moment) since the supplied routines will not, but the Manual file will clearly note what format is and what format is not acceptable to multigram. That's the beauty of open-source software...if you don't like the way it works, you're free to change it to do anything you can imagine whether I think it makes sense or not. Charlie (who may not be an expert, but DOES know how to read) P.S. For those very few people on virtual machines who routinely say, "but I don't HAVE the Manual file, can't find it, and don't want to spend the time to actually LOOK for it since my provider shifted his support costs to the unpaid 'staff' on this mailing list," Peter has posted it right beside the FAQ at http://www.hartzler.net/smartlist/ (with whiz-band direct section links included!) so there's no excuse. Me -- A virtual chihuahua, gnawing on the pantleg of the annoying and foolish. It's futile, but I am undaunted.
(I suppose there is some sensible reason for a mailing list server to retain human names, but it escapes me at the moment)
Here's an example: A club list where the list manager wants to know which club members are on the list, and which people on the list are not (current) club members - since people often have multiple addresses and will sign up for an email list at a diffent address than they supply the club's membership director. Or a list for club or organization directors & officers, where it's way easier to scan the names to see if the appropriate people are on the list than to memorize everyone's email address (esp. when half the people seems to prefer email addresses that are variations on "diver" rather than using their own names). Oooh, I hope I'm not upsetting charlie's delicate ego by daring to offer a thought . . .
At 5:04 PM -0400 7/31/02, Anne Judge annoyed us with:
Here's an example:
Better to be maintained in an external database with the additional data you'd want to store, and generate the dist file from it (possibly a nightly cron job; oh, yeah, another unix command you don't want to hear about - maybe there's a button you can push on the Mac?). I did exactly that for a client using MySQL to maintain the data, PHP to securely manage it remotely, and SmartList to handle the list mailings.
Or a list for club or organization directors & officers
See above, although in this case unless you have hundreds of "directors & officers" most normal people wouldn't need it, since they wouldn't be using a SmartList distribution list as their private address book. (There'd be all that FTPing back-and-forth to do.) Maintaining this information in the distribution file of a mailing list server continues to make no sense whatsoever to me. But again, that's the nice thing about open source; if you take the time to learn it, you can make it do anything you want. If you don't, you're stuck with what you get out-of-the-box.
Oooh, I hope I'm not upsetting charlie's delicate ego by daring to offer a thought . . .
Hardly; it would take someone with actual unix knowledge to challenge my perfectly-healthy ego (like David Linn, who mentioned unlink in a private email and set me researching it since I'm embarassed to admit I never heard of it before). I see it's time for another twit filter, though, to immediately increase the s/n ratio of the list: :0 * ^X-BeenThere: smartlist * ^Received:.*safepages.com * anne.judge /dev/null (safepages.com is in a number of anti-spam filters already for providing cheap drop-box accounts, FWIW. Now I see why.) With this filter in place, you're welcomed to waste time arguing with yourself. Please enjoy the sound of one hand clapping. Charlie -- A virtual chihuahua, gnawing on the pantleg of the truly ignorant. It's futile, of course, but I am undaunted.
In article <v0313033bb96e057fa618@[192.168.123.10]>, Charlie Summers <charlie@lofcom.com> wrote:
At 5:04 PM -0400 7/31/02, Anne Judge annoyed us with:
Here's an example:
Better to be maintained in an external database with the additional data you'd want to store, and generate the dist file from it (possibly a nightly cron job; oh, yeah, another unix command you don't want to hear about - maybe there's a button you can push on the Mac?). I did exactly that for a client using MySQL to maintain the data, PHP to securely manage it remotely, and SmartList to handle the list mailings.
I'm not sure what makes that "better." From SmartList's point of view, the dist list is the canonical location for subscriber info. That's significant. For example, the subscribe, unsubscribe and procbounce scripts all modify the dist file when users need to be added and removed. If you're generating the dist file nightly from a separate database, you're going to wipe out any changes that SmartList made itself during the day. Unless you also modify all the other SmartList scripts and recipes to make their updates to the SQL database first.... at which point the sensible programmer would ask, "is this really a better solution than storing the real names in the dist file?" Now, I consider myself a pretty good hacker and am confident in my ability to understand most any small program if I study it long enough, but so far multigram has eluded me. :-) So I'm not eager to hack multigram to support real names. But I certainly see why it's a desirable solution. I don't understand why you think it's a ridiculous idea and that only stupid Macintosh-using Unix-hating bottom-feeders would want it. In general, you do not want to have two different databases (e.g. a MySQL table and a dist file) that are maintained independently but each considered canonical by different parts of the software system. You are almost guaranteed to end up with stale or inaccurate data in one or both databases as a result. I've been there. It's painful. I don't recommend it. Why do you consider the dist file the wrong place to record this information?
I've been trying to configure Smartlist and have got a mixed bag of problems... I'm trying to create a private list, so have developed an accept list which is an exact duplicate of the dist list. However, some messages not being received by everyone on the dist list. And it appear some users on the accept list are unable to reply or post. And, to make matters worse, some of my users are receiving spam. Can anyone help with thise problems? Thanks, Sue Bott
On [2002-Aug-20] Susan Bott <suebee@jetcityjimbo.com> wrote:
I've been trying to configure Smartlist and have got a mixed bag of problems...
I'm trying to create a private list, so have developed an accept list which is an exact duplicate of the dist list. However, some messages not being received by everyone on the dist list. And it appear some users on the accept list are unable to reply or post.
And, to make matters worse, some of my users are receiving spam.
My first guess is that all of your problems stem from the same problem, i.e. a dist file that isn't formatted correctly. Rich -- richard_ball@merck.com (I regret the presence of the legal disclaimer but I have no control over it) ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ==============================================================================
At 10:38 PM -0400 8/19/02, Susan Bott is rumored to have typed:
I'm trying to create a private list, so have developed an accept list which is an exact duplicate of the dist list.
I'd be interested in knowing what steps you took to make this happen...considering that this is the _default_ of SmartList. (Indeed, accept and dist are hard-linked, so both files point to the same hard drive sectors.) My guess is that by hand-editing the files you managed to create at least some of the problems to which you refer.
However, some messages not being received by everyone on the dist list.
Check your sendmail logs to see if you are delivering to their systems; hotmail/msn users, for example, generally lose a good bit of email routinely. That is, narrow the problem down to see if you are delivering, or not. If you are, it isn't your problem. If you _aren't,_ we need to start looking for another explainiation (and the first place I'd look is in the dist file for a stray control character).
And it appear some users on the accept list are unable to reply or post.
Again, this may have something to do with your, "develop[ing] an accept list which is an exact duplicate of the dist list." I have the feeling this would be less of a problem has you left these files in their default configuration. (If it ain't broke, don't fix it.)
And, to make matters worse, some of my users are receiving spam.
There's little you can do to keep your users from receiving spam; if you do solve their spam problem, please tell me how so I may solve mine as well. (I think what I'm trying to delicately ask is, what the heck does their getting spam have to do with your mailing list?)
Can anyone help with thise problems?
Not really, since to be honest you aren't telling us much. Saying, "they aren't getting the mail," or, "they are getting spam," doesn't exactly narrow the problem(s) down terribly far. Charlie
On [2002-Aug-20] Charlie Summers <charlie@lofcom.com> wrote: [snip]
And, to make matters worse, some of my users are receiving spam.
There's little you can do to keep your users from receiving spam; if you do solve their spam problem, please tell me how so I may solve mine as well. (I think what I'm trying to delicately ask is, what the heck does their getting spam have to do with your mailing list?)
Unless I am misinterpreting her "spam" comment I think she's saying the people on the list are getting spam through the list even though the spammers are not in the accept list and, therefore, shouldn't have their posts accepted. I agree with you that once she gets a working dist file (and a corresponding accept file) then all the problems should go away. Rich -- richard_ball@merck.com (I regret the presence of the legal disclaimer but I have no control over it) ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named on this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ==============================================================================
Is there a way I can specify 2 maintainers for a single list? Thanks, Sue Bott
At 3:06 PM -0400 9/1/02, Susan Bott is rumored to have typed:
Is there a way I can specify 2 maintainers for a single list?
http://www.hartzler.net/smartlist/SmartList-FAQ.html#Section_7.1 Charlie (who says, "Read the FAQ before posting.")
On [2002-Jul-31] Anne Judge <anne.judge@alum.mit.edu> quoted & wrote:
(I suppose there is some sensible reason for a mailing list server to retain human names, but it escapes me at the moment)
Here's an example: A club list where the list manager wants to know which club members are on the list, and which people on the list are not (current) club members - since people often have multiple addresses and will sign up for an email list at a diffent address than they supply the club's membership director.
My need for a real_name <-> email_address connection wasn't strong enough to go the full database route (which is, as Charlie notes, the best full-strength solution) so I opted for just an additional file created during the subscription process. I called it "registry" and it holds just some very basic info on the subscriber. Since all subscription is done by a maintainer via xcommands it was easy enough to restructure the xcommands to handle this, e.g. xcommand .... subscribe <email> name <firstname_lastname> where "name" is a new xcommand which writes the <email> and <firstname_lastname> to the registry file. Richard -- richard_ball@merck.com (I regret the presence of the legal disclaimer but I have no control over it) ------------------------------------------------------------------------------ Notice: This e-mail message, together with any attachments, contains information of Merck & Co., Inc. (Whitehouse Station, New Jersey, USA) that may be confidential, proprietary copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by e-mail and then delete it. ==============================================================================
It seems SmartList doesn't like lists with '+' in their names - createlist complains that createlist: This listname contains magic characters createlist: Support for this is planned, ask on the SmartList createlist: mailinglist for more details So, what's the problem in using +-sign in a listname? What happens if I simply edit createlist to accept them - what will break? Why would I want to do that? I'll explain: I need to set up an automated list creation mechanism: an application server will create lists and manage their contents, yet it should not run a mailserver by itself. The application should not have root access to the mailserver either, it should work so that the mailserver grabs the addresses from the application server and creates or updates the lists accordingly - and even this should preferably be done without root privileges. (I would also keep such lists separate from regular lists, but that's no big deal, just create another userid & directory and recompile flist.) So, I'd need to create and remove lists without altering sendmail alias database every time. I can get around this by naming the lists as "application+list@my.domain" and using virtusertable to convert "list@application.my.domain" into that, but then I'd have to hack Smartlist to understand multiple lists under a single alias. How difficult would that be? That is, I'd have just something like application : "| /something/flist application" application-request : "| /something/flist application-request" in the alias file and then somehow have messages directed to the appropriate list depending on the +-suffix in the address. Now it seems (although I must admit multigram source is a bit hard to read in places) flist cannot handle that by itself. First I thought I'd simply write a procmail script that'd pick the plus sign and pipe the message to "flist application+list", having each list simply named with + sign in it, but trying to create such a list manually failed with the above message. Are there other reasons why the approach outline above would not work? (Any better ideas?) -- Tapani Tarvainen
On or about Mon, Aug 05, 2002 at 01:35:42PM +0300, Tapani Tarvainen typed:
Are there other reasons why the approach outline above would not work? (Any better ideas?)
If you use Exim, you can make it search for the existence of the file $LISTROOT/$LISTNAME/rc.init. This is what I do; it doesn't need to modify anything belonging to the mailserver. I'm sure other MTAs can do similar things. If that's available as an option, you don't need the root access or any of the mucking around you'll have to do with your current scheme. Roger
On Mon, Aug 05, 2002 at 11:48:35AM +0100, Roger Burton West wrote:
If you use Exim, you can make it search for the existence of the file $LISTROOT/$LISTNAME/rc.init. This is what I do; it doesn't need to modify anything belonging to the mailserver. I'm sure other MTAs can do similar things.
If that's available as an option, you don't need the root access or any of the mucking around you'll have to do with your current scheme.
Yes, on second thought I can do it with virtusertable so that "list@application.my.domain" is directed to a procmail recipe that can then pipe it as such to flist, without any need for '+' in the list name. Configuring SmartList to distinguish "list@my.domain" and "list@application.my.domain" should be no problem either... Thanks for the suggestion, -- Tapani Tarvainen
On Mon, Aug 05, 2002 at 03:56:44PM +0300, Tapani Tarvainen wrote:
on second thought I can do it with virtusertable so that "list@application.my.domain" is directed to a procmail recipe that can then pipe it as such to flist, without any need for '+' in the list name.
I meant mailertable, of course. In case anyone is interested (the technique is useful whenever you wish to allow someone to create and remove mailinglists without letting them mess with sendmail alias files &c), here's a summary of how it's done with SmartList & sendmail: (1) Install a new instance of SmartList with suitable permissions using desired subdomain (e.g., "sub.my.domain" - you also need MX record pointing that to your mailserver). You might wish to edit createlist and removelist so they won't say anything about editing aliases, as it's not necessary here. (2) Make sure sendmail has mailertable feature and procmail mailer defined (not just using it as local mailer), i.e., check there's MAILER(`procmail') and FEATURE(`mailertable') in the .mc file. (3) Create mailertable with entry like this: sub.my.domain procmail:/whatever/sub.rc (4) Create /whatever/sub.rc script looking something like this: to=$2 :0 | /something/.bin/flist "`echo $to | cut -d@ -f1`" That's it! Now lists can be created in the subdomain without any need to mess with sendmail aliases or the like, and without confusing them with similar addresses in the main domain. Oh yeah, to be standard-compliant you should also define postmaster@sub.my.domain somehow (e.g., in virtusertable or add it to the procmail script above). That said, I'm still curious about the planned support for special characters in list names createlist alludes to... -- Tapani Tarvainen
Zitat von Tapani Tarvainen <tt@it.jyu.fi>:
I meant mailertable, of course. In case anyone is interested (the technique is useful whenever you wish to allow someone to create and remove mailinglists without letting them mess with sendmail alias files &c), here's a summary of how it's done with SmartList & sendmail:
I didn't try it but it seems to me that the postfix MTA handles this much simpler. A SmartList user can maintain its own alias map which will be used by postfix. It should be no problem to alter the createlist script to modify the alias map. It's not necessary to restart postfix after the change. Werner
participants (10)
-
Anne Judge
-
Charlie Summers
-
Jim Osborn
-
Richard G. Ball
-
Roger Burton West
-
Susan Bott
-
Tapani Tarvainen
-
Tim Pierce
-
Werner Reisberger
-
William Ahern