I need to let the subscribers stay subscribed no matter how many emails bounce from their account. Would assigning minbounce to a blank value as follows do it ?
minbounce = # no. of bounces before removal
Thanks Nishi
"NK" == Nishikant Kapoor nkapoor@webrachna.com writes:
NK> I need to let the subscribers stay subscribed no matter NK> how many emails bounce from their account. Would NK> assigning minbounce to a blank value as follows do it ?
NK> minbounce = # no. of bounces before removal
No, it must be a number.
The trick is to set minbounce and maxhist such that
maxhist < minbounce
This way, the number of remembered bounces can never reach the removal threshold.
Hans-Albert
I am about to put together a small moderation-howto for simple :-) moderators, that is, a collection of instructions for various MUAs, but before going much further I thought of asking if anybody has done such a thing before, or would like to contribute ideas or examples.
I'd also like comments on MUAs that are known to be really unusable.
If I've missed something like this in the web or other old documentation, I would appreciate a pointer (URL or whatever).
For starters, here's what I have in mind for mutt (comments on this are also welcome):
---------------------------------clip--------------------------------- Mutt:
Add the following definition to your .muttrc, substituting your own address and moderator password (if needed):
macro pager \ca '|formail -i "Approved: me@host.domain password" |sendmail -t\n'
Then you can approve a message you are viewing by hitting ctrl-a. ---------------------------------clip---------------------------------
Thank you in advance for any suggestions,
On Mon, Aug 12, 2002 at 12:21:52PM +0300, Tapani Tarvainen wrote:
I am about to put together a small moderation-howto for simple :-) moderators, that is, a collection of instructions for various MUAs
Looks like nobody else has to deal with not-too-computer-savvy moderators... anyway, here's what I came up for pine:
---------------------------------clip--------------------------------- Pine:
(1) Create a script, called (say) "OK", somewhere in your PATH ($HOME/bin or whatever) with contents like this:
#!/bin/sh PATH=/usr/bin:/usr/sbin # depending on where formail and sendmail are MODERATOR=me@my.domain # moderators address PASSWORD=secret # default password (can be empty) formail -i"Approved: $MODERATOR ${1:-$PASSWORD}" | sendmail -t
(2) Make sure you have "enable-unix-pipe-cmd" set in your .pinerc (it can be set via Setup/Configuration menu under "Advanced Command Preferences").
(3) When you want to approve a message, type | OK <return> or if you want to use non-default password, | OK password <return> ---------------------------------clip---------------------------------
I'm not really happy with that but it works and is easy enough to use. Is anybody out there actually using pine for moderating a list? What do you use?
At 4:52 AM -0400 8/13/02, Tapani Tarvainen is rumored to have typed:
Looks like nobody else has to deal with not-too-computer-savvy moderators... anyway, here's what I came up for pine:
Of course we do; however, if they aren't computer-saavy, they likely aren't using pine, or mutt, or elm, or anything else on *nix. They are probably using Outlook Express on Windows, and we have worked around the fact that they CANNOT add arbitrary header fields in various ways; some use the "standard" of applying them to the body, others by more complex password schemes.
This is _not_ to discourage you, only to explain why most of us aren't responding. (If someone is using *nix on their desk machine, they can still use the kludges we've applied for the OE croud, and so don't need to know how to apply custom header fields anyway.)
Charlie
On Tue, Aug 13, 2002 at 10:22:56AM -0400, Charlie Summers wrote:
At 4:52 AM -0400 8/13/02, Tapani Tarvainen is rumored to have typed:
Looks like nobody else has to deal with not-too-computer-savvy moderators...
Of course we do; however, if they aren't computer-saavy, they likely aren't using pine, or mutt, or elm, or anything else on *nix. They are probably using Outlook Express on Windows
I guess I'm in a somewhat unusual environment, but here most non-computer-geeks using email at all use pine (because that's the first thing new students are being taught and second because there're a number of ancient text-only boxes (386s running Linux) available as public-access email boxes around the campus). So I'm faced with a large number of people who use pine for email but are confused by the notion of "command line"... and some diehards using elm (most a bit more computer-savvy but not necessarily much, and they generally don't want to memorize anything new if they can help it); fortunately elm also has | so the solution I suggested for pine works there as well.
As for Outlook Express, well, even people who like Windows (yes, there are such) don't like that monstrosity, and since our Windows admins systematically remove it from new installations nobody learns to use it by default.
I'd still be interested in which (if any) Windows or web-based or even Unix-based GUI-type email clients can manage custom headers comfortably or at all, and how.
(If someone is using *nix on their desk machine, they can still use the kludges we've applied for the OE croud, and so don't need to know how to apply custom header fields anyway.)
But why shouldn't they, when it's the easiest way? As instructions go, "Forward it and insert in the beginning the text 'Approved: ...'" is no easier than "type '|a' and hit return".
Besides I rather want it to be easier on unixy clients... ;-)
--On Wednesday, August 14, 2002 10:35 +0300 Tapani Tarvainen tt@it.jyu.fi wrote:
I'd still be interested in which (if any) Windows or web-based or even Unix-based GUI-type email clients can manage custom headers comfortably or at all, and how.
I'm using Mulberry. There are Windows, Unix, and Mac (9 and X) versions available. In preferences you can add header lines to an identity, then they get added for all emails using that identity. You can have as many identities as you want, and they can inherit from each other. Which identity is used for a specific email is selected from a pull-down menu, with a default (of course). End result: A pull-down menu of what custom header lines you want added to the message.
Daniel T. Staal
------------------------------------------------------------------------ This email copyright the author. Unless otherwise noted, you are expressly allowed to retransmit, quote, or otherwise use the contents for non-commercial purposes. This copyright will expire 5 years after the author's death, or in 30 years, whichever is longer, unless such a period is in excess of local copyright law. ------------------------------------------------------------------------
At 3:35 AM -0400 8/14/02, Tapani Tarvainen is rumored to have typed:
But why shouldn't they, when it's the easiest way?
Because it is NOT necessarily the "easiest way." On our moderated lists, a simple password is placed in the Subject: header field. Others easily add the Approved: header field as the first line of the mail body.
So I would argue that applying a custom header field is the LEAST "easy" method.
Besides I rather want it to be easier on unixy clients... ;-)
What's the difference if I add the approval to the first line of the body in Eudora or pine, Outlook Express or elm?
Honest, you're welcomed to do whatever you wish, and I encourage your efforts; at the same time, I find it interesting that you're applying procmail filters yourself to work around the difficulties; why not apply one of the boatloads of available filters to rc.local.s00 that allow the Approval: to be the first line of the body?
Charlie
On Wed, Aug 14, 2002 at 11:07:06AM -0400, Charlie Summers wrote:
On our moderated lists, a simple password is placed in the Subject: header field. Others easily add the Approved: header field as the first line of the mail body.
So I would argue that applying a custom header field is the LEAST "easy" method.
Well, there're different senses of "easy". I had in mind the ease of use after it's been set up, in terms of time and keystrokes needed.
What's the difference if I add the approval to the first line of the body in Eudora or pine, Outlook Express or elm?
None - *if* you have to do it that way, typing it in.
But it's much easier to just hit ctrl-a after viewing the message in mutt, or even |a<return> in pine or elm.
(OK, a decent editor will allow me to define a macro that does most of it - but pico won't, nor will most of those Windowsy things, I suspect.)
why not apply one of the boatloads of available filters to rc.local.s00 that allow the Approval: to be the first line of the body?
See above. Perhaps it's a personality issue, but if I had to moderate a busy mailing list by "Click Forward, type (or pick from addressbook) the list address again, wait for editor to start, type Approved:..., close editor, send the message" -method, I'd go nuts. And I don't want to tell people they have to do something in a way I wouldn't want to do myself.
That said, I do plan to pick one of those filters, as some people will anyway be using MUAs that can't be dealt with otherwise, and some people do find it easier to type lots of text than having to press <control> even once. But I want to come up with easier method (as I understand it) for those MUAs where it's possible.
Hmm. Perhaps it could be argued that approving a message should not be too easy, at least for people who insist on using idiot MUAs, and offer only the "Insert Approved: at the top of the message" -method, leaving faster ways for those to find who can be bothered to look or at least ask for such...
On Wed, Aug 14, 2002 at 11:07:06AM -0400, Charlie Summers wrote:
On our moderated lists, a simple password is placed in the Subject: header field.
That sounds like a nice idea - it would cope with non-text messages as well, unlike editing the body.
Is the recipe/script(s) you're using freely available somewhere?
Just picking the approval code from Subject: should be easy enough, but unmunging whatever moderator's MUA may have done while resending it sounds harder.
Are you assuming Forward and picking the original From: from the message body and stripping any wrappings added (like "--- Begin forwarded message ---" and the like)?
Doing that for MIME-coded message would be a little harder, but perhaps not too hard. It would need some research on how various MUAs handle forwarding, but those few I tried insert a new text-part in the very beginning of the message in a format that'd be easy to parse without heavy-duty MIME tools. Are you already doing that? If not, any reason why I shouldn't try it?
Incidentally, instead of Subject: it should also be possible to use To: field to pass the approval, in the form
To: Approved: moderator@somewhere password list@listhost
That would have the advantage that "approval" could be defined as an alias or saved as an address in address book, and most MUAs have something like that available.
Hmm. Are there some MUAs or MTAs around that could lose the comment part in the address on the way? Any other reasons not to do it that way?
At 2:09 AM -0400 8/15/02, Tapani Tarvainen is rumored to have typed:
Is the recipe/script(s) you're using freely available somewhere?
No, but it's really quite simple. The company put it together back in the days before there was a moderator_password, and never changed over since the maintainers like it.
Just picking the approval code from Subject: should be easy enough, but unmunging whatever moderator's MUA may have done while resending it sounds harder.
Are you assuming Forward and picking the original From: from the message body and stripping any wrappings added (like "--- Begin forwarded message ---" and the like)?
No, lord no...you're assuming a forward instead of a redirect. Redirecting an email message in reasonable clients eliminates all of those problems. (Don't ask me about OE; I said, "reasonable.")
Incidentally, instead of Subject: it should also be possible to use To: field to pass the approval, in the form
Ain't open-source software wonderful? You can use anything you want; From: header field, perhaps?
Charlie
On Thu, Aug 15, 2002 at 09:19:15AM -0400, Charlie Summers wrote:
Is the recipe/script(s) you're using freely available somewhere?
No, but it's really quite simple. The company put it together back in the days before there was a moderator_password, and never changed over since the maintainers like it.
Yeah, if you only move the password from Subject: to a separate Approve: header it's indeed simple.
Are you assuming Forward and picking the original From:
No, lord no...you're assuming a forward instead of a redirect. Redirecting an email message in reasonable clients eliminates all of those problems. (Don't ask me about OE; I said, "reasonable.")
Hmm. I figured clients that cannot add custom header lines couldn't do that either... are there really such that draw the line there, that can redirect with new subject but cannot add new header lines? Even pine's Bounce command won't do, it doesn't let you change the Subject... (although probably it could be done by some deep magic, role templates or whatever), which is one reason I thought of using To: -field instead.
Incidentally, instead of Subject: it should also be possible to use To: field to pass the approval
Ain't open-source software wonderful?
Indeed. :-)
You can use anything you want; From: header field, perhaps?
Changing the From field is again difficult in many clients (although usually doable), whereas changing To: is something all of them can do (indeed even all _users_, if they can use email at all). Anyway, here's my first attempt at "approve-via-To:-field":
:0 Hfw *^(Resent-|)To: *"*Approved: | sed -e 's/^([^:]*:) *"*(Approved:.*)"* *(<.*>)/\1 \3\ \2/
Put that in rc.local.s00 and send approvals by To: "Approved: ..." list@listhost either with Bounce/Redirect (which will retain correct headers) or Forward (which will munge them but gets the message through). That should be easy enough even for OE users.
Seems to work - anybody spot problems in it? Like, are there mail clients out there that Redirect without adding Resent-To: -field? (Well, even if there are they'd be no worse than OE...)
"TT" == Tapani Tarvainen tt@it.jyu.fi writes:
TT> I'd still be interested in which (if any) Windows or TT> web-based or even Unix-based GUI-type email clients can TT> manage custom headers comfortably or at all, and how.
I am using the VM mode of (Emacs or) XEmacs on Solaris and Linux (never tried VM mode on Windows).
In the compose window, there is a line separating header and body. It reads "--text follows this line--". You simply add your headers above that line. That's all.
Hans-Albert
smartlist@lists.rwth-aachen.de
-
Charlie Summers -
Daniel Staal -
Hans-Albert Schneider -
Nishikant Kapoor -
Tapani Tarvainen