Hello. How might one configure Mailman (version 2.1.6) list settings
using PHP scripts? The goal is to configure Mailman list settings such as
domain name of list, non-digest footer, set welcome/goodbye messages, etc.
An approach that comes to mind is to use bin/config_list. This would
require writing/reading files and using bin/config_list to process them.
Is there another recommended or preferred way to accomplish this?
There was a post about "PHP Wrappers" which suggested, "...just use a
setuid mailman wrapper script that does caller-checking to see if it's
called correctly, by the right user, and with 'safe' values"
<http://mail.python.org/pipermail/mailman-developers/2001-March/008421.html>.
This was recommended over simply adding the www user to the mailman group.
I do not completely understand how one creates a setuid mailman wrapper
script. Is this a matter of creating something similar to mail-wrapper.c?
If someone has written a wrapper script or has some good resources further
explaining this to share and is willing to do so, I would appreciate it.
Thank you,
-Adrian
I'm developing a patch to add an XMLRPC-based management interface to
Mailman. Would this be something that you would be interested in trying
to incorporate in the 2.1.x branch? Thanks!
-jag
--
Joshua Ginsberg <jag(a)fsf.org>
Free Software Foundation - Senior Systems Administrator
Tokio Kikuchi wrote:
>> http://www.securityfocus.com/bid/16248/discuss
>> GNU Mailman Large Date Data Denial Of Service Vulnerability
>> GNU Mailman is prone to a denial of service attack. This issue affects
>> the
>> email date parsing functionality of Mailman.
(snip)
>> 06.3.18 CVE: CVE-2005-4153
(snip)
>
> Mailman-2.1.7 is not vulnerable to this issue.
>
We may have to patch against this email package parsedate bug.
I've just uploaded a patch on SF tracker. Please someone review this
before I commit in the CVS (this weekend, maybe).
https://sourceforge.net/tracker/?func=add&group_id=103&atid=300103
Cheers,
--
Tokio Kikuchi, tkikuchi@ is.kochi-u.ac.jp
http://weather.is.kochi-u.ac.jp/
Dan Astoorian wrote:
>
>Personally, I'm of the opinion that it's wrong ever to use a reject rule
>for spam filtering in the first place, since so much spam has forged
>sender information anyway, but debating that is well beyond the scope of
>how this bug should be fixed.
I think we all agree that 'spam' should be discarded or maybe held for
examination by a human, but never rejected.
The problem I see is that while header_filter_rules are in the Spam
filters section of the admin interface and enforced by a module named
SpamDetect, they can actually be used in other ways to reject messages
which are not 'spam' per se.
>However, I agree with Mark that discarding instead of rejecting feels
>wrong.
>
>Would checking the x-beenthere: headers to avoid the loop not be a far
>cleaner solution, or is there some reason I've overlooked why that
>wouldn't work?
X-Been-There: won't work because it's never added in messages to -owner.
Perhaps we could test if msg.get_sender() == mlist.GetOwnerEmail(), and
discard in that case only, but I'd want a somewhat different test in
case the sender's domain were not identical - something like
if msg.get_sender().split('@')[0] == \
mlist.GetOwnerEmail().split('@')[0]:
--
Mark Sapiro <msapiro(a)value.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
Is there any reason to not put admin_member_chunksize in the GUI?
It doesn't do the job requested in
<http://sourceforge.net/tracker/index.php?func=detail&aid=782436&group_id=10…>,
but it helps.
Is there a fear that some unsuspecting list owner will set it too big?
--
Mark Sapiro <msapiro(a)value.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
To refresh, see
<http://mail.python.org/pipermail/mailman-developers/2005-November/018395.ht…>
and
<http://mail.python.org/pipermail/mailman-developers/2005-December/018449.ht…>.
The problem with set_payload() creating a message for which a
subsequent get_payload did 'too much' decoding was fixed by having
Scrubber.py add a 'X-Mailman-Scrubbed: Yes' header upon doing a
set_payload(), and then in various places where there are subsequent
get_payload() calls, setting the decode flag according to the presence
or absence of the header.
I actually like the header as an explanation of content change along
the lines of X-Content-Filtered-By:, but I've been uneasy about
setting the get_payload() decode flag based on the presence or absence
of 'X-Mailman-Scrubbed: Yes', although it seems to work in all cases
we've tried.
Recently, I looked in more detail at the actual set_payload() method in
the email library and I have at least a vague understanding of the
problem. The problem and my understanding are reported at
<http://sourceforge.net/tracker/?func=detail&aid=1409455&group_id=5470&atid=…>.
I have suggested a patch there which I call a 'Hint at possible fix'.
This patch could be applied in Scrubber.py.
The patch to Scrubber.py would add to the end of the
def replace_payload_by_text(msg, text, charset):
definition making the whole definition
def replace_payload_by_text(msg, text, charset):
# TK: This is a common function in replacing the attachment and the
main
# message by a text (scrubbing). Also, add a flag indicating it
has been
# scrubbed.
del msg['content-type']
del msg['content-transfer-encoding']
msg.set_payload(text, charset)
msg['X-Mailman-Scrubbed'] = 'Yes'
if msg.get('content-transfer-encoding') == 'quoted-printable':
cset = msg.get_charset()
if cset:
msg._payload = cset.body_encode(msg._payload)
msg._charset = None
The advantage to doing this in Scrubber.py and unconditionally setting
the decode flag for subsequent get_payload() calls is it makes the
whole process insensitive to whether or not or when Python email bug #
1409455 is fixed. If the bug is fixed, the payload will be encoded and
msg.get_charset() above will return None so the payload won't be
encoded a second time. The additional code above can be removed at
some point after we're sure the email library used by Mailman is fixed.
--
Mark Sapiro <msapiro(a)value.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
Dan Astoorian wrote:
>On Fri, 27 Jan 2006 12:52:17 PST, Mark Sapiro writes:
>>
>> Definitely the message received by the user in this case is misleading,
>> but the held message if approved will go to the owners/moderators
>> only. I think Dan knows this.
>
>Actually, I didn't. I'm a co-moderator of a mailing list that I didn't
>initially set up, so my experience with Mailman is fairly limited. I've
>never previously encountered a held message that was to any mail path
>other than the list itself, and had never had cause to find out whether
>other types of mail ever got held up for approval. In my declaration
>that "it is not clear to the end user...", I was the end user in
>question :-)
OK
>(Perhaps the moderation queue web interface should indicate which queue
>the held message is in? Currently the moderator has to infer this
>information from the message headers.)
Actually, as you implicitly point out, this isn't necessary since only
list posts should be in the moderation queue in the first place. The
only other messages that currently get held are messages to the owner
that get caught by a Spam filter 'hold' rule, and these shouldn't be
held. At least that's how it seems pending other input.
--
Mark Sapiro <msapiro(a)value.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
Dan Astoorian posted to the bug tracker:
>Specifically: it is (IMHO) probably incorrect to apply
>the "Hold" action to messages which were not submitted
>to the list address. For example, a message sent to
>"listname-owner" and matched by a "Hold"
>header_filter_rule should not be held for approval
>(irrespective of whether the message was administrivia
>or not).
Good point.
>(It is not clear to the end user whether approving such
>a held message would cause the message to be delivered
>to the original "listname-owner" address, or whether it
>would be sent to the list itself.)
Definitely the message received by the user in this case is misleading,
but the held message if approved will go to the owners/moderators
only. I think Dan knows this.
>I suspect (but have not verified) that similar issues
>may exist for other mail paths (e.g., -request, -admin,
>-(un)subscribe).
Unless you are seeing something I'm not, this is not the case. The
issue is that SpamDetect.py is in both the GLOBAL_PIPELINE and the
OWNER_PIPELINE, but messages to
-request|join|leave|subscribe|unsubscribe|admin|bounces|confirm are
not processed through SpamDetect.py and are never held for any reason.
>Probably the most sensible thing to do with messages
>that match a "Hold" rule would be to hold the message
>only if the "tolist" key is set; otherwise, do one of
>the following:
>a) continue on to the next rule, as though the "Hold"
>rule failed to match the message;
>b) accept the message; or
>c) discard the message.
>
>It's not clear to me which of these options makes the
>most sense. Discarding the message is probably unwise,
>as a "hold" rule in the first place suggests that the
>administrator does not consider all mail that matches
>the rule to be expendable.
I think b) accept the message is the correct action since the 'hold
rule' implies the owner/moderator wants to see the message and
accepting the message sends it to the owners/moderators.
--
Mark Sapiro <msapiro(a)value.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
I have just uploaded a patch to Sourforge that allows you to set
sitewide headers and footers for the Mailman 2.1.7 web UI,
[ 1415956 ] Sitewide headers/footers & XHTML Compliant Web UI
This patch was borne out of a request I received to
make the Mailman UI fit the look of the web site. This
patch allows you to set a site wide header and footer.
This allows you to pretty much make the MM UI look like
any other site. While I was at it I also made the web
UI XHTML compliant.
Once you patch your source and install it, all you need
to do is edit the html files in the templates/en
directory. Most of the pages will get the header and
footers from the site-header.html and site-footer.html
files, but some of the HTML files already contain theor
own header/footer so you will need ot edit some of
these files as well.
Since this also adds XHTML compliance, this superceeds
patch #116035
You can dowload it (and a separate version that works with the
ht://dig integration patches) from:
https://sourceforge.net/tracker/index.php?func=detail&aid=1415956&group_id=…
You can see in use at http://databaseadvisors.com/mailman/listinfo
--
Bryan Carbonnell - carbonnb(a)gmail.com
Life's journey is not to arrive at the grave safely in a well
preserved body, but rather to skid in sideways, totally worn out,
shouting "What a great ride!"
On Wed, 18 Jan 2006 17:00:52 +0100
Brad Knowles <brad(a)stop.mail-abuse.org> wrote:
> At 12:01 AM -0800 2006-01-17, J C Lawrence wrote:
>> Long time no talk. Whaddya think of adding message_id as a
>> replaceable token for footers and the like? This would allow footers
>> to be constructed which direct URL-reference their own post in an
>> NNTP archive.
> I like the concept, but the only problem is that message-ids are not
> guaranteed unique. I'd like to see a guaranteed unique id be
> generated on the system, and then have that used as the new
> message-id, displayable in the footers, used as the index reference in
> the mailing list archives, etc....
While true (the non-guarantee), in working across a quarter million
messages in the archives of my various lists I've hit less than a score
of duplicate or missing Message-IDs. That's a small enough problem that
I'm willing to just eat the conflicts.
--
J C Lawrence They said, "You have a blue guitar,
---------(*) You do not play things as they are."
claw(a)kanga.nu The man replied, "Things as they are
http://www.kanga.nu/~claw/ Are changed upon the blue guitar."