> The bottom line is, like the original poster of this thread, I
> want these headers to go away. Unfortunately, I haven't been able
> to find where they are coming from. If someone could simply tell
> me what I need to hack in order to get rid of these headers, I
> would be grateful.
http://nl
> "BW" == Bill Warner <[EMAIL PROTECTED]> writes:
>> But, Mailman could do a better job of conforming to RFC 2369.
>> E.g. it could suppress List-Post: for read-only lists,
BW> Or, as Chuq mentioned use the List-Post: NO syntax.
That's what I meant to say. :)
>> Whether th
Well then I would have to say the duplicates are being created at my end.
At 22:58 8/05/01 -0700, Chuq Von Rospach wrote:
>On 5/8/01 10:57 PM, "David Casamento" <[EMAIL PROTECTED]> wrote:
>
> > So from what I can tell, my mailing list server is sending out all the
> dups.
>
>But that doesn't tel
Hi,
Apologies if this is in the archives (how do you search for Mailman specific
topics?), but I would like to enable the "hide" option for all subscribers
to a particular list. Is there a way to do that from the CLI?
--
Juha
The malformed orange
Fails to satisfy the eye:
Segmentation fault.
On Wed, 09 May 2001 15:33:47 -0500
Bill Warner <[EMAIL PROTECTED]> wrote:
> At 12:15 AM 5/9/01 -0700, J C Lawrence wrote:
>> Actually I buy and agree with both arguments, I just consider
>> them misplaced in this case. They work very well elsewhere.
> I think they are appropriate here too. It
> > check_perms should be finding all this; you need to find out what's going
> > wrong with check_perms.
>
> I tested with changing permissions/ownerships around on a few things
> to see what check_perms would and would not catch, and found an
> something interesting: Check_perms wants to set
On Wed, 9 May 2001, Dan Mick wrote:
> Doublecheck your version of check_perms; the code is there, and it
> works, in 2.0.5. Are you running check_perms from the installed
> bin/ directory as the instructions and about a billion posts on this
> list say?
Yes. I did.
> check_perms should be find
Tib ([EMAIL PROTECTED]) said something that sounded like:
> [root@unica mailman]# ls -lR lists/|grep config.db
Are the directories set-gid? This will help in some cases where things
are not ran through a set-gid program. Make sure that they are set to
be 2775 (drwxrwsr-x).
Ciao,
--
Pug Bainte
> Check_perms fails to find it, and it's turning into a major problem.
Doublecheck your version of check_perms; the code is there, and it
works, in 2.0.5. Are you running check_perms from the installed
bin/ directory as the instructions and about a billion posts on this
list say?
> What (exac
Check_perms fails to find it, and it's turning into a major problem.
What (exactly) writes and rewrites the config.db file and what are the actual
permissions it's supposed to have? From ealier reference it sounded as though
it should be owned by nobody (since the webserver
modifies/creates/backs
I'm afraid it doesn't - here's an example:
[root@unica mailman]# ls -lR lists/|grep config.db
-rw-rw1 nobody mail 9759 May 9 14:14 config.db
-rw-rw1 nobody mail 9759 May 9 14:14 config.db.last
-rw-rw1 mailman mail16876 May 9 15:27 config.db
Apparently you didn't read what I said.
> -rw-rw1 nobody mail16875 May 8 18:16
> /home/mailman/lists/thelist/config.db
is not group mailman. That would be the problem, and I have to believe
that check_perms would find it, too.
> > The web server writes it. This is not a pro
On 5/9/01 1:33 PM, "Bill Warner" <[EMAIL PROTECTED]> wrote:
> OTOH, a strident "hack it or take a hike" anti-configuration stance (some
> of the messages in the archive are downright hostile) actually makes it
> harder for me, and others, to migrate towards full 2369 compliance, which
> means it
At 01:29 PM 5/9/01 -0400, Barry A. Warsaw wrote:
>On the larger question of the List-* headers, there's no doubt that
>the situation will not change for the 2.0.x maintenance branch. If
>you want to get rid of the headers, hack the source.
Fair enough.
>But, Mailman could do a better job of con
At 12:15 AM 5/9/01 -0700, J C Lawrence wrote:
>There is a critical difference. X does allow you and even makes it
>very easy to do damned near anything you want, encluding being
>incredibly stupid and making bad decisions. In a general light,
>this is not a Bad Thing. One critical aspect howeve
At 11:32 PM 5/8/01 -0700, Chuq Von Rospach wrote:
>I disagree. Policy decisions should be made by people who can make them in
>an informed way, not out of ignorance. X windows lets its users do REALLY
>STUPID AND DESTRUCTIVE things, simply because they want to. "because they
>want to" isn't a good
Sorry for the off-topic post, but at least I confessed my sin in
advance!
Since this group really seems to know its stuff, I'd like to ask
for recommendations for a webmail server that will run on
the same RHL7 machine as my Mailman installations. I'm hosting
several low-traffic domains fo
To help out those of you who like me think we should have the option of
removing the headers, here is my CookHeaders.py which removes all
headers that Mailman adds to outgoing mail. This is the crude way of
doing it, but my users are happier now and I have fewer complaints.
Myself and another gent
At 2001-05-09 13:29 -0400, Barry A. Warsaw wrote:
>Mike, thanks for the Eudora suggestions. I'm going to create a
>README.USERAGENT file that collects this wisdom, and I'm going to add
>a FAQ entry pointing people to this file. If anybody else has
>suggestions on settings for other MUAs please s
Mike, thanks for the Eudora suggestions. I'm going to create a
README.USERAGENT file that collects this wisdom, and I'm going to add
a FAQ entry pointing people to this file. If anybody else has
suggestions on settings for other MUAs please send them along.
On the larger question of the List-*
for starters, is there an archive available of this [EMAIL PROTECTED]
list so can look thru?
trying to find out where to locate the file that holds the subscriber's
addresses on the server. does mailman take well to having scripts edit the
users instead of the conventional subscribe or admin bul
On Wed, 9 May 2001, Jason Maderios wrote:
> Are all the available attributes listed anywhere? I would like to add
> the username and password to the footer of every email sent out. I know
> about the security implications but this is for a short term
> "Announcement" list.
You can't. The MLM d
>Same with hacking list-*. The general consensus among those of us who've put
>time into understanding this issue is that it's a very good thing for the
>long-term development of mail list technologies. Short term, it's at best a
>minor irritant, and that's only to people with cruddy mail clients
Attached is a script that i wrote a week or two ago to do exactly that.
you might need to edit the top line to reflect the location of python on
your system. I had the script sitting in ~mailman/bin on my system and it
worked quite happily.
If you want to run it in cron, schedule it to run just b
Gang,
Are all the available attributes listed anywhere? I would like to add
the username and password to the footer of every email sent out. I know
about the security implications but this is for a short term
"Announcement" list.
TIA,
Jason Maderios
--
At 06:02 PM 5/8/2001 -0600, Ashley M. Kirchner wrote:
>Chuq Von Rospach wrote:
>
>> Trying to keep the subscriber databases in sync across machines is going to
>> be problematic.
>
>Tow things I can think off of the top of my head, one being the easiest
>(maybe).
>
> a) NFS
Not
On Tue, 8 May 2001, Pug Bainter wrote:
| Joe Morris ([EMAIL PROTECTED]) said something that sounded like:
| > 4. Rerun check_perms and it finds 11 problems all related to files that
| > are not set-gid. Why did it return differently this time after I set the
| > owner of all files to mailman?!?
On May 9, 2001 at 09:51, Nigel Metheringham wrote:
>will not in general support them... and currently the only MUA I know
>of that does use them is exmh (and that has a couple of wrinkles I
Pine, at least since 4.21, supports List-*.
>We probably also ought to use the List-* headers as part o
Hi there...
We are running a mailman site with 6 Lists. All the lists bar the Rouge one are
working like a dream.
The rogue list is sending out a sent message multiple times, with the amount of times
ranging from 2 to 100 odd times. There is no difference in
setup of the lists, and I have even
[EMAIL PROTECTED] said:
> If and when MUAs make automated use of these headers as suggested by
> the RFC, then it may be a good idea. But until then, I simply can't
> afford the added tech support burden to teach every user how to make
> this kind of config change to their particular client.
30 matches
Mail list logo
