? This very message came to me with the following header:
Errors-To: mailman-developers-admin(a)python.org
All my bounces come to the list admin address, set in
the admin webpage, in the second field of General Options.
Do you have that set to something, and bounces still come to root?
> 2. Bounces are sent to the poor postmaster instead of a -admin address.
> I'm not entirely certain, but I think an Errors-To: header or something
> like that in all Mailman messages might allow one to distribute that load
> somewhat.
This the official announcement for Mailman 2.1 alpha 2. Because it's
an alpha, this announcement is only going out to the mailman-* mailing
lists. I'll make two warnings: you probably should still not use this
version for production systems (but TIA for any and all testing you do
with it!), and I've already had a couple of bug fixes from early
adopters. 2.1a2 should still be useful, but you might want to keep an
eye on cvs and the mailman-checkins list for updates.
I am only making the tarball available on SourceForge, so you'll need
to go to http://sf.net/projects/mailman to grab it. You'll also need
to upgrade to mimelib-0.4, so be sure to go to
http://sf.net/projects/mimelib to grab and install that tarball first.
To view the on-line documentation, see
http://www.list.org/MM21/index.html
or
http://mailman.sf.net/MM21/index.html
Below is an excerpt from the NEWS file for all the changes since
2.1alpha1. There are a bunch of new features coming down the pike,
and I hope to have an alpha3 out soon. I'm also planning on doing
much more stress testing of this version with real list traffic, and
I'm hoping we'll start to get more languages integrated into cvs.
Enjoy,
-Barry
-------------------- snip snip --------------------
2.1 alpha 2 (11-Jul-2001)
- Building
o mimelib 0.4 is now required. Get it from
http://mimelib.sf.net. If you've installed an earlier
version of mimelib, you must upgrade.
o /usr/local/mailman is now the default installation
directory. Use configure's --prefix switch to change it
back to the default (/home/mailman) or any other
installation directory of your choice.
- Security
o Better definition of authentication domains. The following
roles have been defined: user, list-admin, list-moderator,
creator, site-admin.
o There is now a separate role of "list moderator", which has
access to the pending requests (admindb) page, but not the
list configuration pages.
o Subscription confirmations can now be performed via email or
via URL. When a subscription is received, a unique (sha)
confirm URL is generated in the confirmation message.
Simply visiting this URL completes the subscription process.
o In a similar manner, removal requests (via web or email
command) no longer require the password. If the correct
password is given, the removal is performed immediately. If
no password is given, then a confirmation message is
generated.
- Internationalization
o More I18N patches. The basic infrastructure should now be
working correctly. Spanish templates and catalogs are
included, and English, French, Hungarian, and Big5 templates
are included.
o Cascading specializations and internationalization of
templates. Templates are now search for in the following
order: list-specific location, domain-specific location,
site-wide location, global defaults. Each search location
is further qualified by the language being displayed. This
means that you only need to change the templates that are
different from the global defaults.
Templates renamed: admlogin.txt => admlogin.html
Templates added: private.html
- Web UI
o Redesigned the user options page. It now sits behind an
authentication so user options cannot be viewed without the
proper password. The other advantage is that the user's
password need not be entered on the options page to
unsubscribe or change option values. The login screen also
provides for password mail-back, and unsubscription w/
confirmation.
Other new features accessible from the user options page
include: ability to change email address (with confirmation)
both per-list and globally for all list on virtual domain;
global membership password changing; global mail delivery
disable/enable; ability to suppress password reminders both
per-list and globally; logout button.
[Note: the handle_opts cgi has gone away]
o Color schemes for non-template based web pages can be defined
via mm_cfg.
o Redesign of the membership management page. The page is now
split into three subcategories (Membership List, Mass
Subscription, and Mass Removal). The Membership List
subcategory now supports searching for member addresses by
regular expression, and if necessary, it groups member
addresses first alphabetically, and then by chunks.
Mass Subscription and Mass Removal now support file upload,
with one address per line.
o Hyperlinks from the logos in the footers have been removed.
The sponsors got too much "unsubscribe me!" spam from
desperate user of Mailman at other sites.
o New buttons on the digest admin page to send a digest
immediately (if it's non-empty), to start a new digest
volume with the next digest, and to select the interval with
which to automatically start a new digest volume (yearly,
monthly, quarterly, weekly, daily).
DEFAULT_DIGEST_VOLUME_FREQUENCY is a new configuration
variable, initially set to give a new digest volume monthly.
o Through-the-web list creation and removal, using a separate
site-wide authentication role called the "list creator and
destroyer" or simply "list creator". If the configuration
variable OWNERS_CAN_DELETE_THEIR_OWN_LISTS is set to 1 (by
default, it's 0), then list admins can delete their own
lists.
This feature requires an adaptor for the particular MTA
you're using. An adaptor for Postfix is included, as is a
dumb adaptor that just emails mailman@yoursite with the
necessary Sendmail style /etc/alias file changes. Some MTAs
like Exim can be configured to automatically recognize new
lists. The adaptor is selected via the MTA option in
mm_cfg.py
- Email UI
o In email commands, "join" is a synonym for
"subscribe". "remove" and "leave" are synonyms for
"unsubscribe". New robot addresses are support to make
subscribing and unsubscribing much easier:
mylist-join@mysite
mylist-leave@mysite
o Confirmation messages have a shortened Subject: header,
containing just the word "confirm" and the confirmation
cookie. This should help for MUAs that like to wrap long
Subject: lines, messing up confirmation.
o Mailman now recognizes an Urgent: header, which, if it
contains the list moderator or list administrator password,
forces the message to be delivered immediately to all
members (i.e. both regular and digest members). The message
is also placed in the digest. If the password is incorrect,
the message will be bounced back to the sender.
- Performance
o Refinements to the new qrunner subsystem which preserves
FIFO order of messages.
o The qrunner is no longer started from cron. It is started
by a Un*x init-style script called bin/mailmanctl (see
below). cron/qrunner has been removed.
- Command line scripts
o bin/mailmanctl script added, which is used to start, stop,
and restart the qrunner daemon.
o bin/qrunner script added which allows a single sub-qrunner
to run once through its processing loop.
o bin/change_pw script added (eases mass changing of list
passwords).
o bin/update grows a -f switch to force an update.
o bin/newlang renamed to bin/addlang; bin/rmlang removed.
o bin/mmsitepass has grown a -c option to set the list
creator's password. The site-wide `create' web page is
linked to from the admin overview page.
o bin/newlist's -o option is removed. This script also grows
a way of spelling the creation of a list in a specific
virtual domain.
o The `auto' script has been removed.
o bin/dumpdb has grown -m/--marshal and -p/--pickle options.
o bin/list_admins can be used to print the owners of a mailing list.
o bin/genaliases regenerates from scratch the aliases and
aliases.db file for the Postfix MTA.
- Archiver
o New archiver date clobbering option, which allows dates to
only be clobber if they are outrageously out-of-date
(default setting is 15 days on either side of received
timestamp). New configuration variables:
ARCHIVER_CLOBBER_DATE_POLICY
ARCHIVER_ALLOWABLE_SANE_DATE_SKEW
The archived copy of messages grows an X-List-Received-Date:
header indicating the time the message was received by
Mailman.
o PRIVATE_ARCHIVE_URL configuration variable is removed (this
can be calculated on the fly, and removing it actually makes
site configuration easier).
- Miscellaneous
o Several new README's have been added.
o Most syslog entries for the qrunner have been redirected to
logs/error.
o On SIGHUP, qrunner will re-open all its log files and
restart all child processes. See "bin/mailmanctl restart".
- Patches and bug fixes
o SF patches and bug fixes applied: 420396, 424389, 227694,
426002, 401372 (partial), 401452.
o Fixes in 2.0.5 ported forward:
Fix a lock stagnation problem that can result when the
user hits the `stop' button on their browser during a
write operation that can take a long time (e.g. hitting
the membership management admin page).
o Fixes in 2.0.4 ported forward:
Python 2.1 compatibility release. There were a few
questionable constructs and uses of deprecated modules
that caused annoying warnings when used with Python 2.1.
This release quiets those warnings.
o Fixes in 2.0.3 ported forward:
Bug fix release. There was a small typo in 2.0.2 in
ListAdmin.py for approving an already subscribed member
(thanks Thomas!). Also, an update to the OpenWall
security workaround (contrib/securelinux_fix.py) was
included. Thanks to Marc Merlin.
I've gotten several bug reports on SF for people who can't get to the admin
pages
The only error apache gives me is:
[Thu Jul 12 15:47:17 2001] [error] [client 171.71.41.31] Premature end of
script headers: /var/local/mailman/cgi-bin/admin
I never had the problem myself and it seems to come and go
Is there any debugging I can in mailman to at least give me some error in my
apache error log? (or do you think it's an apache problem?)
Attached is one of the tickets I've gotten
Thanks,
Marc
----- Forwarded message from noreply(a)sourceforge.net -----
To: noreply(a)sourceforge.net
From: noreply(a)sourceforge.net
Subject: [ alexandria-Support Requests-438992 ] Administration interface to mail lists
Date: Thu, 26 Jul 2001 02:43:44 -0700
Support Requests item #438992, was opened at 2001-07-06 00:49
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=200001&aid=438992&group_id…
Category: Mailing Lists
Group: Second Level Support
>Status: Open
Priority: 9
Submitted By: Richard Leyton (rleyton)
Assigned to: Marc Merlin (marcmerlin)
Summary: Administration interface to mail lists
Initial Comment:
A post to a mailing list needs admin attention (it's a
moderated list). The URL:
http://lists.sourceforge.net/lists/admindb/leap-announce
results in:
Internal Server Error
The server encountered an internal error or
misconfiguration and was unable to complete your request.
Please contact the server administrator,
staff(a)sourceforge.net and inform them of the time the
error occurred, and anything you might have done that
may have caused the error.
More information about this error may be available in
the server error log.
Could you look into it.
----------------------------------------------------------------------
>Comment By: Richard Leyton (rleyton)
Date: 2001-07-26 02:43
Message:
Logged In: YES
user_id=7704
In a nutshell, this ceased to be a problem the next day, i'd
forgotten about this ticket until the status changed.
I had given a detailed response to your queries, but mozilla
crashed on me before i clicked on the submit, and i was in a
hurry, so i didn't get around to reposting it.
in a nutshell:
- all browsers tried (opera, netscape & mozilla)
- had a URL via e-mail to attend to pending admin requests.
- yes it gave the same error with netscape
- it was the message received on going to the URL contained
in the e-mail.
----------------------------------------------------------------------
Comment By: Marc Merlin (marcmerlin)
Date: 2001-07-25 11:14
Message:
Logged In: YES
user_id=6500
We need the information if you want us to help you
----------------------------------------------------------------------
Comment By: Marc Merlin (marcmerlin)
Date: 2001-07-17 08:38
Message:
Logged In: YES
user_id=6500
What browser? Does it fail repeatetly from different places?
Does it fail with plain netscape?
Does it fail when you access the page, or when you post back
a form?
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=200001&aid=438992&group_id…
----- End forwarded message -----
--
Microsoft is to operating systems & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | Finger marc_f(a)merlins.org for PGP key
[Note: I'm moving this discussion to malman-developers. -baw]
>>>>> "JAA" == Jose A Accino <jaccino(a)ieev.uma.es> writes:
JAA> Is there any clean way to make a smooth upgrade from 2.0b5 to
JAA> lates 2.1a2? (I'm making that just to check the upgrade
JAA> process, using a spare machine and a copy of the actual
JAA> lists).
JAA> Making a 2.1a2 fresh installation (without lists) runs fine.
JAA> However, I've been unable to upgrade the old lists. Here are
JAA> the main points:
There's two ways to upgrade, neither of which has gotten a lot of
testing. Based on you're message I tried the first way, and I'm about
to check in a bunch of patches to make that go smoother. I'll try the
second way soon.
1) Install a fresh virgin MM2.1 in /usr/local/mailman and then move
lists from /home/mailman (MM2.0.x) to /usr/local/mailman. This way
lets you migrate lists one at a time, gaining confidence in the new
system in measured increments. I will probably upgrade
{python,zope}.org this way.
2) Install MM2.1 overtop an existing MM2.0.x installation and have
everything just magically work. I'll probably upgrade wooz.org's
production lists this way.
Both ought to work, and ought to be easy. After the checkins, here's
a recipe that makes #1 easy:
- Do a fresh install of MM2.1 in /usr/local/mailman according to the
instructions.
- Copy or move `mylist' by first moving /home/mailman/lists/mylist
to /usr/local/mailman/lists/mylist and
/home/mailman/archives/private/mylist.mbox to
/usr/local/mailman/archives/private
BTW, I used rsync for this, just cause it's a cool tool and I can
actually remember how to invoke it with the right options. :)
That's it. Everything else should just work, except for possibly two
minor complications.
- If your web server is going to support both installations, it's
possible you'll have two different base urls, one for your MM2.0.x
installation and one for your MM2.1 installation. If so, you'll
need to manually change each moved list's web_page_url attribute.
Fortunately, I'm about to add a script called `fix_url' which will
reset a list's web_page_url to mm_cfg.DEFAULT_URL. So if you
configure mm_cfg.py correctly, then run fix_url, you should be
golden. I.e.
% bin/withlist -l -r fix_url mylist
- Same dealie with your MTA, i.e. your wrapper aliases may point to
two different directories. Here, because I use Postfix and glued
them together as described in README.POSTFIX, all I needed to do was
run bin/genaliases and the new list aliases got installed.
I'm sure that if you use Exim and glued them together as per
README.EXIM, you probably don't need to do anything. (I'm still
waiting on contributions for better gluing instructions for
Sendmail, qmail, and any others.)
-Barry
Bug: in Mailman/Handlers/ToUsenet.py, there are spaces inserted after
colons where they are missing ("NNTP is strict about spaces after the
colon in headers").
If a colon appears in a continuation line, it is treated as a header
colon.
Fix: skip lines that start with whitespace.
For those interested, the history of the finding of the bug:
Problem: my signed emails appeared on Usenet garbled. The multipart
boundary had an extra space inserted (which of course the actual
boundaries hadn't).
After some exchange with Martin Armstrong (who made me aware of this)
we concluded it had to be the mail->news gateway (as my direct mail to
him, also signed, wasn't garbled).
I then investigated ToUsenet.py, and found the error.
Why this hasn't hit a lot more often is simple: most MUA seem to use
some random gibberish as the boundary string. SEMI doesn't...
Of course, if this is fixed in 2.1, you can ignore this (assuming that
it comes out soonish ;-)
Bye, J
--
Jürgen A. Erhard (juergen.erhard(a)gmx.net, jae(a)users.sourceforge.net)
MARS: http://members.tripod.com/Juergen_Erhard/mars_index.html
Life's Better Without Braces (http://www.python.org)
I wish I had more energy -- or less ambition.
Hi,
I've already submitted a bug to SF about this, but I can confirm that if I set
dont_respond_to_post_requests to NO then this seems to arise a bug in Hold.py,
i.e. the variable lang is not set and I get the following error:
Aug 30 16:43:04 2001 (17624) Uncaught runner exception: Local variable 'lang' referenced before
assignment
Aug 30 16:43:04 2001 (17624) Traceback (most recent call last):
File "/home/mailman/Mailman/Queue/IncomingRunner.py", line 134, in _dopipeline
sys.modules[modname].process(mlist, msg, msgdata)
File "/home/mailman/Mailman/Handlers/Hold.py", line 145, in process
hold_for_approval(mlist, msg, msgdata, ModeratedPost)
File "/home/mailman/Mailman/Handlers/Hold.py", line 277, in hold_for_approval
charset=Utils.GetCharSet(lang))
UnboundLocalError: Local variable 'lang' referenced before assignment
I think that the patch is quite simple, but I'm not yet able to provide it :)
MM 2.1a2.
Regards,
Luca
Finally! Here's the patch to avoid sending out list duplicates to
users who don't want it. This is a solution to the never-ending
feuding on various Debian mailing lists about whether or not people
should Cc: folks already on the list; hopefully, this
user-configurable behavior will make everyone's lives easier.
This patch is against mailman CVS.
The patch adds a DontReceiveDuplicates flag to mm_cfg (value 128). By
default, this is 0, which is the same as our current behavior.
If DontReceiveDuplicates is set to 1 for the user, then they will not
receive a list message if:
1) the qrunner process has already set a mail with that message-id to
that user
-or-
2) the user is specifically listed in the To:, Cc:, Resent-To:, or Resent-Cc:
fields.
If DontReceiveDuplicates is set to 0 and Personalization is enabled
for the list, a X-Mailman-Duplicate: yes will be added to every
duplicate message sent out (not the first) to allow users to filter
for themselves.
I have not done any i18n for this code, mea culpa. But the option is
settable via the web interface or the mail interface. (it's the
"nodupes" option via mail.)
Issues:
1) What happens if people fake their Message-IDs? It's possible (but
hard) to stop real list mail from coming through to someone who
doesn't get duplicates, if you send out lots of messages with the same
Message-ID.
2) Does this use a lot of memory? I'm using a two-level hash to store
the message IDs and email addresses that have been seen; I don't know
if this will grow huge on big sites.
3) Is there any way to add the X-Mailman-Duplicate: yes header to various
users when the admin is not using Personalization on the lists?
4) If multiple qrunner processes end up handling mails, it's possible
a user who doesn't want duplicates will get them. How can we fix
this?
5) Some users probably don't want list duplicates if the message is
addressed to multiple lists that they belong to, but DO want
duplicates if they're specifically listed in To:/Cc:/etc. Should we
make yet another option for this?
Please, comments are definitely appreciated. The patch works for me,
as long as the previous patch I sent to the list (allowing users to
actually set options) is applied.
This and my previous patches are all available at:
http://nausicaa.interq.or.jp/mailman/
Patch follows.
diff -x CVS -x messages -ruN mailman.orig/Mailman/Cgi/options.py mailman/Mailman/Cgi/options.py
--- mailman.orig/Mailman/Cgi/options.py Thu Aug 2 13:14:43 2001
+++ mailman/Mailman/Cgi/options.py Tue Aug 28 22:10:21 2001
@@ -375,6 +375,7 @@
('conceal', mm_cfg.ConcealSubscription),
('remind', mm_cfg.SuppressPasswordReminder),
('rcvtopic', mm_cfg.ReceiveNonmatchingTopics),
+ ('nodupes', mm_cfg.DontReceiveDuplicates),
):
try:
newval = int(cgidata.getvalue(item))
@@ -449,9 +450,18 @@
global_remind = newval
break
- if global_enable is not None or global_remind is not None:
+ global_nodupes = None
+ if cgidata.getvalue('nodupes-globally'):
+ for flag, newval in newvals:
+ if flag == mm_cfg.DontReceiveDuplicates:
+ global_nodupes = newval
+ break
+
+ if (global_enable is not None or global_remind is not None
+ or global_nodupes is not None):
for gmlist in lists_of_member(mlist.host_name, user):
- global_options(gmlist, user, global_enable, global_remind)
+ global_options(gmlist, user, global_enable, global_remind,
+ global_nodupes)
# Now print the results
if cantdigest:
@@ -526,6 +536,10 @@
mlist.FormatOptionButton(mm_cfg.ConcealSubscription, 0, user))
replacements['<mm-hide-subscription-button>'] = mlist.FormatOptionButton(
mm_cfg.ConcealSubscription, 1, user)
+ replacements['<mm-dont-receive-duplicates-button>'] = (
+ mlist.FormatOptionButton(mm_cfg.DontReceiveDuplicates, 1, user))
+ replacements['<mm-receive-duplicates-button>'] = (
+ mlist.FormatOptionButton(mm_cfg.DontReceiveDuplicates, 0, user))
replacements['<mm-unsubscribe-button>'] = (
mlist.FormatButton('unsub', _('Unsubscribe')) + '<br>' +
CheckBox('unsubconfirm', 1, checked=0).Format() +
@@ -555,6 +569,8 @@
CheckBox('deliver-globally', 1, checked=0).Format())
replacements['<mm-global-remind-button>'] = (
CheckBox('remind-globally', 1, checked=0).Format())
+ replacements['<mm-global-nodupes-button>'] = (
+ CheckBox('nodupes-globally', 1, checked=0).Format())
days = int(mm_cfg.PENDING_REQUEST_LIFE / mm_cfg.days(1))
if days > 1:
@@ -741,7 +757,7 @@
-def global_options(mlist, user, global_enable, global_remind):
+def global_options(mlist, user, global_enable, global_remind, global_nodupes):
def sigterm_handler(signum, frame, mlist=mlist):
# Make sure the list gets unlocked...
mlist.Unlock()
@@ -762,6 +778,10 @@
if global_remind is not None:
mlist.setMemberOption(user, mm_cfg.SuppressPasswordReminder,
global_remind)
+
+ if global_nodupes is not None:
+ mlist.setMemberOption(user, mm_cfg.DontReceiveDuplicates,
+ global_nodupes)
mlist.Save()
finally:
diff -x CVS -x messages -ruN mailman.orig/Mailman/Defaults.py.in mailman/Mailman/Defaults.py.in
--- mailman.orig/Mailman/Defaults.py.in Tue Aug 21 00:04:21 2001
+++ mailman/Mailman/Defaults.py.in Tue Aug 28 21:15:10 2001
@@ -269,6 +269,7 @@
'Hold',
'Tagger',
'CalcRecips',
+ 'AvoidDuplicates',
'Cleanse',
'CookHeaders',
'ToDigest',
@@ -722,6 +723,7 @@
ConcealSubscription = 16
SuppressPasswordReminder = 32
ReceiveNonmatchingTopics = 64
+DontReceiveDuplicates = 128
# Authentication contexts.
#
diff -x CVS -x messages -ruN mailman.orig/Mailman/HTMLFormatter.py mailman/Mailman/HTMLFormatter.py
--- mailman.orig/Mailman/HTMLFormatter.py Sat Aug 18 06:18:43 2001
+++ mailman/Mailman/HTMLFormatter.py Tue Aug 28 21:15:31 2001
@@ -117,6 +117,7 @@
mm_cfg.ConcealSubscription : 'conceal',
mm_cfg.SuppressPasswordReminder : 'remind',
mm_cfg.ReceiveNonmatchingTopics : 'rcvtopic',
+ mm_cfg.DontReceiveDuplicates : 'nodupes',
}[type]
return '<input type=radio name="%s" value="%d"%s>' % (
name, value, checked)
diff -x CVS -x messages -ruN mailman.orig/Mailman/Handlers/AvoidDuplicates.py mailman/Mailman/Handlers/AvoidDuplicates.py
--- mailman.orig/Mailman/Handlers/AvoidDuplicates.py Thu Jan 1 09:00:00 1970
+++ mailman/Mailman/Handlers/AvoidDuplicates.py Tue Aug 28 22:17:46 2001
@@ -0,0 +1,118 @@
+# Copyright (C) 1998,1999,2000,2001 by the Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License
+# as published by the Free Software Foundation; either version 2
+# of the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+"""If the user wishes it, do not send duplicates of the same message.
+
+This module keeps an in-memory dictionary of Message-ID and recipient
+pairs. If a message with an identical Message-ID is about to be sent
+to someone who has already received a copy, we either drop the message,
+add a duplicate warning header, or pass it through, depending on the
+user's preferences.
+"""
+
+import string
+
+from Mailman import mm_cfg
+from Mailman import Utils
+from Mailman import Message
+from Mailman import Errors
+from Mailman.i18n import _
+from mimelib.address import getaddresses
+
+
+
+class DuplicateDetected(Errors.DiscardMessage):
+ """The message would have been sent multiple times to a user who
+ prefers not to receive duplicates."""
+
+# A dictionary of dictionaries, used to store which recipients have received
+# which message IDs.
+recip_msgids = {}
+
+
+
+def process(mlist, msg, msgdata):
+
+ recips = msgdata['recips']
+ msgid = msg.get('message-id')
+
+ if not recips or not msgid:
+ return
+
+ # This dictionary will hold recips who want their mail to have
+ # the X-Mailman-Duplicate: yes header.
+ if not msgdata.has_key('add-dupe-header'):
+ msgdata['add-dupe-header'] = {}
+
+ # Happily borrowed from mimelib.getaddresses() example
+ tos = msg.getall('to')
+ ccs = msg.getall('cc')
+ resent_tos = msg.getall('resent-to')
+ resent_ccs = msg.getall('resent-cc')
+ external_recips = getaddresses(tos + ccs + resent_tos + resent_ccs)
+
+ # Anyone mentioned in the to/cc/resent-to/resent-cc headers should
+ # not get a duplicate of the message.
+ for (name, email) in external_recips:
+
+ # If getaddresses fails, email could be null. Skip those.
+ if not email:
+ continue
+
+ # Initialize the external recipient's msgid hash if this is the
+ # first email they've received with this message-id.
+ if not recip_msgids.has_key(email):
+ recip_msgids[email] = {}
+
+ # We don't do anything except record that that address has
+ # gotten or will get a copy of this email externally.
+ recip_msgids[email][msgid] = 1
+
+ newrecips = []
+
+ for r in recips:
+ if not recip_msgids.has_key(r):
+ recip_msgids[r] = {}
+
+ # If they have received a message with this message-id already,
+ # see if they don't want duplicates.
+ if recip_msgids[r].has_key(msgid):
+ send_duplicate = 1
+
+ # If the member wants to receive duplicates, or if the recipient
+ # is not a member at all, just flag the X-Mailman-Duplicate: yes
+ # header.
+ try:
+ if mlist.getMemberOption(r, mm_cfg.DontReceiveDuplicates):
+ send_duplicate = 0
+ except Errors.NotAMemberError:
+ pass
+
+ # We'll send a duplicate unless the user doesn't wish it.
+ # If personalization is enabled, the add-dupe-header flag will
+ # add a X-Mailman-Duplicate: yes header for this user's message.
+ if send_duplicate:
+ msgdata['add-dupe-header'][r] = 1
+ newrecips.append(r)
+
+ else:
+ # Otherwise, this is the first time they've been in the recips
+ # list. Add them to the newrecips list and flag them as having
+ # received this message.
+ recip_msgids[r][msgid] = 1
+ newrecips.append(r)
+
+ msgdata['recips'] = newrecips
diff -x CVS -x messages -ruN mailman.orig/Mailman/Handlers/Personalize.py mailman/Mailman/Handlers/Personalize.py
--- mailman.orig/Mailman/Handlers/Personalize.py Sat Aug 18 06:20:58 2001
+++ mailman/Mailman/Handlers/Personalize.py Tue Aug 28 21:10:17 2001
@@ -46,11 +46,23 @@
msg['To'] = '%s (%s)' % (member, name)
else:
msg['To'] = member
+
+ # We can flag the mail as a duplicate for each member, if
+ # they've already received that message. (See AvoidDuplicates.py)
+ if msgdata['add-dupe-header'].has_key(member):
+ msg['X-Mailman-Duplicate'] = 'yes'
+ elif msg.has_key('X-Mailman-Duplicate'):
+ del msg['X-Mailman-Duplicate']
+
inq.enqueue(msg, metadatacopy, listname=mlist.internal_name())
# Restore the original To: line
del msg['To']
msg['To'] = originalto
+
+ # The original message is not a duplicate.
+ if msg.has_key('X-Mailman-Duplicate'):
+ del msg['X-Mailman-Duplicate']
# Don't let the normal ToOutgoing processing actually send the original
# copy.
diff -x CVS -x messages -ruN mailman.orig/Mailman/MailCommandHandler.py mailman/Mailman/MailCommandHandler.py
--- mailman.orig/Mailman/MailCommandHandler.py Fri Aug 17 14:37:15 2001
+++ mailman/Mailman/MailCommandHandler.py Tue Aug 28 21:19:44 2001
@@ -80,27 +80,36 @@
you get digests in MIME format, which are much better if you have a mail
reader that supports MIME.""")
-option_desc = {'hide' : HIDE,
- 'nomail' : NOMAIL,
- 'ack' : ACK,
- 'notmetoo': NOTMETOO,
- 'digest' : DIGEST,
- 'plain' : PLAIN,
+NODUPES = _("""When turned on, you do *not* receive duplicate mails if mail is
+sent to multiple lists that you belong to. This option will let you avoid
+duplicate mails; if you turn it on, you will never receive multiple copies
+of the same message. Also, if you *and* the list are mentioned explicitly
+in the To: or Cc: headers of a message, you will not receive duplicates if
+this is turned on.""")
+
+option_desc = {'hide' : HIDE,
+ 'nomail' : NOMAIL,
+ 'ack' : ACK,
+ 'notmetoo' : NOTMETOO,
+ 'digest' : DIGEST,
+ 'plain' : PLAIN,
+ 'nodupes' : NODUPES,
}
# jcrey: and then the real one
_ = Mailman.i18n._
-option_info = {'hide' : mm_cfg.ConcealSubscription,
- 'nomail' : mm_cfg.DisableDelivery,
- 'ack' : mm_cfg.AcknowledgePosts,
- 'notmetoo': mm_cfg.DontReceiveOwnPosts,
- 'digest' : 0,
- 'plain' : mm_cfg.DisableMime,
+option_info = {'hide' : mm_cfg.ConcealSubscription,
+ 'nomail' : mm_cfg.DisableDelivery,
+ 'ack' : mm_cfg.AcknowledgePosts,
+ 'notmetoo' : mm_cfg.DontReceiveOwnPosts,
+ 'digest' : 0,
+ 'plain' : mm_cfg.DisableMime,
+ 'nodupes' : mm_cfg.DontReceiveDuplicates
}
# ordered list
-options = ('hide', 'nomail', 'ack', 'notmetoo', 'digest', 'plain')
+options = ('hide', 'nomail', 'ack', 'notmetoo', 'digest', 'plain', 'nodupes')
# strip just the outer layer of quotes
quotecre = re.compile(r'["\'`](?P<cmd>.*)["\'`]')
diff -x CVS -x messages -ruN mailman.orig/templates/en/help.txt mailman/templates/en/help.txt
--- mailman.orig/templates/en/help.txt Sat May 19 06:28:54 2001
+++ mailman/templates/en/help.txt Tue Aug 28 21:21:56 2001
@@ -79,6 +79,10 @@
Conceals your address when people look at who is on this
list.
+ nodupes:
+ Turn this on if you do not want to receive duplicate mail
+ from the list, in case you are explicitly in the To: or Cc:
+ fields already or are included in multiple lists in one message.
options
Show the current values of your list options.
diff -x CVS -x messages -ruN mailman.orig/templates/en/options.html mailman/templates/en/options.html
--- mailman.orig/templates/en/options.html Thu Jul 19 06:54:40 2001
+++ mailman/templates/en/options.html Tue Aug 28 22:09:46 2001
@@ -280,6 +280,26 @@
<mm-receive-nonmatching-topics>Yes
</td></tr>
+ <tr><td bgcolor="#cccccc">
+ <strong>Avoid duplicate copies of messages?</strong><p>
+
+ When you are listed explicitly in the To: or Cc: headers
+ of a list message, or a message is sent to multiple lists
+ that you are a member of, you can opt to not receive another
+ copy from the mailing list. Select <em>Yes</em> to avoid
+ receiving duplicate copies from the mailing list; select
+ <em>No</em> to receive duplicate copies.
+
+ <p>If the list has per-message personalization
+ enabled, every duplicate mail will have a
+ <tt>X-Mailman-Duplicate: yes</tt> header added to it.
+
+ </td><td bgcolor="#cccccc">
+ <mm-receive-duplicates-button>No<br>
+ <mm-dont-receive-duplicates-button>Yes<p>
+ <mm-global-nodupes-button><i>Set globally</i>
+ </td></tr>
+
<tr><TD colspan="2">
<center><MM-options-Submit-button></center>
</td></tr>
--
Brought to you by the letters M and V and the number 8.
"Hoosh is a kind of soup."
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
I was able to get Mailman 2.1a2 working on my SuSe 7.2 box. I have done
some testing and all seems to be working fine. Nice job Barry!
I have been customizing the listinfo pages and can't seem to find where I
can change the text displayed with <MM-Editing-Options>. Is there any way
to change this info? or is it hard coded into a module. If so then which
module, I think I could hack it from there.
Also, one other thing, in the README docs that talks about customizing
the install, a blurb about how to edit the user interface pages might be a
needed addition. I went back into the list archives to learn how to make
custom list specific pages. But some users won't go to that extent.
TIA
Wayne Ringling
All,
I'd hoped that Mailman would let me have "closed" lists in the sense
that I could reject anything from outside of 'atg.com'.
forbidden_posters[], I figured, was implemented to take a regular
expression. Instead, it seems that Utils.py implements
FindMatchingAddresses(...), which returns an *exact match* of an
address. This isn't the behavior that I'd hoped for, since (a) we're
sure to have open lists that are only used internally and (b)
So, I guess that I have two questions:
1. What would be wrong with having something like this:
# in a list's config
forbidden_posters = ['^.*(a)(?!atg.com$)', 'another_regex_here', 'etc...']
# from Handlers/Hold.py
addrs = Utils.FindMatchingAddresses(sender, forbiddens)
if addrs:
hold_for_approval(mlist, msg, msgdata, ForbiddenPoster)
...
def FindMatchingAddresses(sender, forbiddens):
res = []
for each_banned in forbiddens:
p = re.compile(each_banned)
m = p.match(each_banned)
if m != None:
res.append(each_banned)
return res
2. Instead of hold_for_approval(...), would anyone have any objections
if a method like kill_forbidden_message(...) was implemented? We
have many, many lists and often times a list administrator (the
users themselves) won't think to delete messages that are blocked,
yet get held for approval.
--
Nate Patwardhan
Art Technology Group
********************************************
$ ping elvis
elvis is alive
Barry A. Warsaw writes:
> Leaving politics aside, what I like about texinfo (or latex as with
> the Python documentation) is that you can write it with any text
> editor/word processor in the world. That means that anybody can
That's true for man pages as well, but the markup is a bit more
obscure and more presentation-driven than it should be, but that's a
minor issue given the heavy use of convention in man pages.
> contribute documentation. It's also fairly easy to generate
> PostScript for hardcopy, or HTML for online browsing, among other
> formats. The toolchain is widely available and stable. And there's
This is true for man pages as well; a properly-written & marked man
page can have a very nice printed form.
> enough semantic and structural markup so that it shouldn't be hard to
> convert it to the document format du jour (e.g. DocBook, but I could
> be blowing it out my ass on that one ;).
I'm standing back! ;-) But this is where Texinfo improves on the
troff -man markup; it generally relies less on convention and
template-driven authoring to get the job done, so is easier to
convert.
> I really like how the Python documentation is done. It has way more
> than we need for Mailman so I'm not suggesting it. I'm trying to
Both more and less, as we've discussed.
> avoid the endless religious arguments about documentation format by
> just saying texinfo is Good Enough, I have a lot of experience writing
> stuff in it, and it should be easy enough to learn for anybody who can
> contribute.
My keyboard doesn't have an "@" key. ;-)
> As for man pages, I don't disagree that they're damn useful. I
> /would/ like to see man pages for all the bin/* scripts, but that's
> just a tiny fraction of the potentially useful Mailman documentation
> we could provide. And I don't think the description of system use
> from -- 1) the user's point of view; 2) the list owner/moderator's
> point of view; 3) the site administrators point of view -- would be
> well served by man page format.
I agree. DocBook would solve both the general documentation and man
page problem. So go with DocBook like I told you. ;-)
Seriously, the common tools for DocBook leave something to be
desired, especially for typeset formats. Writting a better tool would
not be terribly hard these days, especially if you went with the XML
version of DocBook.
-Fred
--
Fred L. Drake, Jr. <fdrake at acm.org>
PythonLabs at Zope Corporation