Mailman 3 April 2006 - Mailman-coders

[ mailman-Patches-657951 ] Generate RSS summary in archives
by SourceForge.net 19 Aug '22

19 Aug '22

Patches item #657951, was opened at 2002-12-23 14:17 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i… Category: Pipermail Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 7 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Generate RSS summary in archives Initial Comment: Here's a first-draft patch. Things that need fixing: * The generated RSS feed needs to be validated. (It passed the W3C's RDF validator, but RSS validators still need to be checked.) * The date should be given in YYYY-MM-DD format, which requires parsing the .fromdate attribute. * How do I get the URL for an archived message? The generated RSS currently just uses the filename, which is wrong. How do I get at the PUBLIC_ARCHIVE_URL setting? * Getting the most recent N postings is inefficient; the code loops through all of the archived messages and takes the last N of them. We could add .last() and .prev() methods to the Database class, but that's more ambitious for 2.1beta than I like. (Would be nice to get this into 2.1final...) * The list index page should have a LINK element pointing to the RSS file. Please make any comments you have, and I'll rework the patch accordingly. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-18 18:43 Message: Logged In: YES user_id=12800 Andrew, to get the url for the archived message use mlist.GetBaseArchiveURL(), which knows about private vs. public archives, the host name and the list name. From there you should be able to tack on just the part of the path under "archives/private/listname". See Mailman/Handlers/Scrubber.py for an example. Only other minor comment: NUM_ARTICLES can probably go in Defaults.py.in ---------------------------------------------------------------------- Comment By: Justin Mason (jmason) Date: 2003-03-26 16:49 Message: Logged In: YES user_id=935 big thumbs up from me too. Much better solution than http://taint.org/mmrss/ ;) ---------------------------------------------------------------------- Comment By: Uche Ogbuji (uche) Date: 2003-03-17 20:09 Message: Logged In: YES user_id=38966 I'd like to add my vote to this item. This is a fantastic idea, Andrew. Thanks. --Uche ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 15:42 Message: Logged In: YES user_id=11375 Updated patch: * Dates are now rendered as ISO-8601 (date only, not the time of the message) * By hard-wiring 2002-December, I got the RSS to validate using Mark Pilgrim's validator. ---------------------------------------------------------------------- Comment By: captain larry (captainlarry) Date: 2002-12-23 14:36 Message: Logged In: YES user_id=147905 Just voting for support here. This is *great* thanks for the patch and I hope the maintainers include it as soon as it's appropriate :) Adam. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-23 14:27 Message: Logged In: YES user_id=12800 Deferring until post-2.1 ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 14:21 Message: Logged In: YES user_id=11375 Argh; SF choked on the file upload. Attaching the patch again... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i…

2 1

[ mailman-Bugs-1256272 ] NNTP gatewaying trashes Message-IDs
by SourceForge.net 29 Apr '06

29 Apr '06

Bugs item #1256272, was opened at 2005-08-11 00:47 Message generated for change (Comment added) made by kateturner You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1256272&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: nntp/news Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Kate Turner (kateturner) Assigned to: Nobody/Anonymous (nobody) Summary: NNTP gatewaying trashes Message-IDs Initial Comment: when a message is relayed to NNTP, the NewsRunner unconditionally replaces the existing Message-ID with its own. this breaking threading when reading a list via news, and when an NNTP user replies to a list message. a better solution would be either: 1) do not rewrite the message-id unless the NNTP server reports an error when posting it (duplicate ID); or 2) optionally, always rewrite posters' message-ids into a mailman-generated ID, and use this ID for both mail and news. i have implemented the former at our site and it appears to work, but it's so ugly i'd not feel comfortable submitting a patch for it. ---------------------------------------------------------------------- >Comment By: Kate Turner (kateturner) Date: 2006-04-29 15:44 Message: Logged In: YES user_id=1116721 the conflicts occur when a user cross-posts a message to two lists. the newsrunner won't turn it into a cross-post, instead it tries to post it separately to both groups, and the news server rejects the second one for a duplicate message-id (tested with innd). of course, you could say this behaviour is a bug too :) i'm not sure what the best way to group cross-posted messages is, since they won't be received by the same mailman instance. (cancelling the first and re-posting to both groups might work, but i don't know if inn will still record the message-id and not allow it to be reused.) ---------------------------------------------------------------------- Comment By: Ian Z. (nobrowser) Date: 2006-04-20 06:13 Message: Logged In: YES user_id=1192798 Finally! I thought I was the only one who noticed this. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346413 Why would the mail message-id ever cause a conflict with the NNTP server? message-ids are supposed to be globally unique and there is a convention (in RFC 2822?) that ensures it (put in the FQDN and something unique to the generating software). So I think 1) is not ugly but correct :) 2) wouldn't completely solve the problem. I can post one copy of a message to a mailman list and another directly to another recipient, including myself. (I actually Cc myself on all mail I send). If mailman does 2), the extra recipient will still be confused. Ian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1256272&group_…

1 0

[ mailman-Bugs-1471487 ] ASCII decoding error in membership management
by SourceForge.net 28 Apr '06

28 Apr '06

Bugs item #1471487, was opened at 2006-04-16 16:32 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471487&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Andreas Thienemann (ixsnet) Assigned to: Nobody/Anonymous (nobody) Summary: ASCII decoding error in membership management Initial Comment: When opening the list membership management view in the admin interface, a notice about hitting a bug in 2.1.7 appears. The error log has some more information: admin(31507): [----- Mailman Version: 2.1.7 -----] admin(31507): [----- Traceback ------] admin(31507): Traceback (most recent call last): admin(31507): File "/opt/mailman-2.1.7/scripts/driver", line 101, in run_main admin(31507): main() admin(31507): File "/opt/mailman-2.1.7/Mailman/Cgi/admin.py", line 197, in main admin(31507): show_results(mlist, doc, category, subcat, cgidata) admin(31507): File "/opt/mailman-2.1.7/Mailman/Cgi/admin.py", line 497, in show_results admin(31507): form.AddItem(membership_options(mlist, subcat, cgidata, doc, form)) admin(31507): File "/opt/mailman-2.1.7/Mailman/Cgi/admin.py", line 869, in membership_options admin(31507): all = [_m.encode() for _m in mlist.getMembers()] admin(31507): UnicodeError: ASCII decoding error: ordinal not in range(128) admin(31507): [----- Python Information -----] admin(31507): sys.version = 2.2.3 (#1, Nov 11 2003, 17:44:56) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] admin(31507): sys.executable = /usr/bin/python2 admin(31507): sys.prefix = /usr admin(31507): sys.exec_prefix = /usr admin(31507): sys.path = /usr admin(31507): sys.platform = linux2 ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-04-28 15:42 Message: Logged In: YES user_id=1123998 > Would an illegal address such as this be filtered nowadays? Yes, such an address couldn't be added in the first place. ---------------------------------------------------------------------- Comment By: Andreas Thienemann (ixsnet) Date: 2006-04-28 14:32 Message: Logged In: YES user_id=1450459 It seems, the problem is caused by an illegal email address "marionmÃ¼ller(a)t-online.de". And yes, this was an upgrade from 2.0.x. Would an illegal address such as this be filtered nowadays? ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-16 18:51 Message: Logged In: YES user_id=1123998 Did you just upgrade from Mailman 2.1.2 or older? It appears that this list has one or more members with (invalid?) non-ascii characters in their email address. I think any version from 2.1.3 on would throw this exception, and no recent version would allow the address to be added. You might try something like bin/list_members listname | egrep '[^[:alnum:]@.-]' to find the offending address. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471487&group_…

1 0

[ mailman-Bugs-1471487 ] ASCII decoding error in membership management
by SourceForge.net 28 Apr '06

28 Apr '06

Bugs item #1471487, was opened at 2006-04-16 23:32 Message generated for change (Comment added) made by ixsnet You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471487&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Andreas Thienemann (ixsnet) Assigned to: Nobody/Anonymous (nobody) Summary: ASCII decoding error in membership management Initial Comment: When opening the list membership management view in the admin interface, a notice about hitting a bug in 2.1.7 appears. The error log has some more information: admin(31507): [----- Mailman Version: 2.1.7 -----] admin(31507): [----- Traceback ------] admin(31507): Traceback (most recent call last): admin(31507): File "/opt/mailman-2.1.7/scripts/driver", line 101, in run_main admin(31507): main() admin(31507): File "/opt/mailman-2.1.7/Mailman/Cgi/admin.py", line 197, in main admin(31507): show_results(mlist, doc, category, subcat, cgidata) admin(31507): File "/opt/mailman-2.1.7/Mailman/Cgi/admin.py", line 497, in show_results admin(31507): form.AddItem(membership_options(mlist, subcat, cgidata, doc, form)) admin(31507): File "/opt/mailman-2.1.7/Mailman/Cgi/admin.py", line 869, in membership_options admin(31507): all = [_m.encode() for _m in mlist.getMembers()] admin(31507): UnicodeError: ASCII decoding error: ordinal not in range(128) admin(31507): [----- Python Information -----] admin(31507): sys.version = 2.2.3 (#1, Nov 11 2003, 17:44:56) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] admin(31507): sys.executable = /usr/bin/python2 admin(31507): sys.prefix = /usr admin(31507): sys.exec_prefix = /usr admin(31507): sys.path = /usr admin(31507): sys.platform = linux2 ---------------------------------------------------------------------- >Comment By: Andreas Thienemann (ixsnet) Date: 2006-04-28 21:32 Message: Logged In: YES user_id=1450459 It seems, the problem is caused by an illegal email address "marionmÃ¼ller(a)t-online.de". And yes, this was an upgrade from 2.0.x. Would an illegal address such as this be filtered nowadays? ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 01:51 Message: Logged In: YES user_id=1123998 Did you just upgrade from Mailman 2.1.2 or older? It appears that this list has one or more members with (invalid?) non-ascii characters in their email address. I think any version from 2.1.3 on would throw this exception, and no recent version would allow the address to be added. You might try something like bin/list_members listname | egrep '[^[:alnum:]@.-]' to find the offending address. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471487&group_…

1 0

[ mailman-Feature Requests-1234579 ] hiding e-mail addresses in public archive
by SourceForge.net 26 Apr '06

26 Apr '06

Feature Requests item #1234579, was opened at 2005-07-08 05:13 Message generated for change (Comment added) made by eht16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1234579&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Abracode (abracode) Assigned to: Nobody/Anonymous (nobody) Summary: hiding e-mail addresses in public archive Initial Comment: I would love to see an option to hide e-mail addresses of senders in the public archive - only in the archive and only e-mails, not names. Simple e-mail obfuscation (like joe at schmo.com) is not good enough nowadays with more and more advanced/malicious e-mail harvesters. Thanks, Tom ---------------------------------------------------------------------- Comment By: eht16 (eht16) Date: 2006-04-26 14:57 Message: Logged In: YES user_id=1117045 As a workaround I modified some code in HyperArch.py. The patch is available at http://www.uvena.de/patches/mailman_hide_email.patch. Surely, it can be made better, but I'm no python hacker and it just works for the moment. I patched mailman version 2.1.5. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-19 20:38 Message: Logged In: YES user_id=12800 Please add this as a comment to the Mailman 2.2 wiki page: http://wiki.list.org/display/DEV/Mailman+2.2 The idea is to implement all archive access as a dynamic process (cgi) and then we'll be able to modify the obfuscation algorithm on the fly as older methods become obsolete. ---------------------------------------------------------------------- Comment By: eht16 (eht16) Date: 2006-04-19 20:29 Message: Logged In: YES user_id=1117045 I also need this feature. Are there any news about it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1234579&group_…

1 0

[ mailman-Feature Requests-1156871 ] Facilitate delivery of membership lists to listowners
by SourceForge.net 23 Apr '06

23 Apr '06

Feature Requests item #1156871, was opened at 2005-03-04 11:00 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1156871&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Willie McKemie (mckemie) Assigned to: Nobody/Anonymous (nobody) Summary: Facilitate delivery of membership lists to listowners Initial Comment: Seemingly, customers of hosting services that offer MailMan have no convenient way to backup list memberships. list_members is generally not accessible. A email delivered "who" command does not deliver addresses that are hidden. Addresses can not be globally un-hidden. Web page presented membeship lists are available only in small batches. Possible solutions: 1) a "who" command or replacement that deliveries the entire membershiip list 2) a, possiblly temorary, global "un-hiding" of addresses so that "who" will supply the entire membership list 3) a web page option that will delivery the entire list by email or other means. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-04-23 11:32 Message: Logged In: YES user_id=1123998 Note that there are scripts available for "screen scraping" the admin Membership pages to get a complete list including if desired, all the members settings except language. See the FAQ at http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.062.htp I understand this isn't an implementation of the request, but it does provide a work around. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2005-03-15 02:36 Message: Logged In: YES user_id=564396 another (in my opinion: good) idea would be the ability to additionally extract the per-list settings of the subscribed users (e.g. if they have set their "no-mail" flag) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1156871&group_…

1 0

[ mailman-Patches-943827 ] true virtual hosting patch for 2.1
by SourceForge.net 22 Apr '06

22 Apr '06

Patches item #943827, was opened at 2004-04-29 02:57 Message generated for change (Comment added) made by tbble You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=943827&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: The Anarcat (anarcat) Assigned to: Nobody/Anonymous (nobody) Summary: true virtual hosting patch for 2.1 Initial Comment: [copy of the mail sent to -developpers@] We developped a reliable solution for running lists with the same name on different domains on the same Mailman installation. I implemented that on top of the Mailman 2.1.1-5.1 Debian stable package. All that is needed is to patch 2 files (bin/newlist, Mailman/MailList.py) in the mailman install, and here is the patch: http://bugs.koumbit.net/file_download.php?file_id=3&type=bug There's only one caveat right now: Mailman/Cgi/create.py might need to get patched too, but I haven't got around looking at it yet, and it "just works", for now. I don't know what's the current status of virtual hosting support on Mailman, but this patch is a simple hack that should bring joy in the homes of all Mailman admins around the world. :) I got my inspiration and part of the code from: http://mithrandr.moria.org/blog/139.html All it does is to add the domain to the internal_name() of a list. The real_name is kept as is, and the getListAddress() does the Right Thing. This makes Mailman generate aliases like: list-example.com: "|/var/lib/mailman/mail/mailman post list-example.com" Care will have to be taken on the MTA side to map those list-example.com to list(a)example.com. We are using alternc.org to manage our server, so we are using LDAP, so everything went pretty smoothly. :) But I guess it will require some magic on the Postfix side or something... Cheers, A. PS: for those wanting to see more, you can come to our Wiki: http://koumbit.net/wiki/VirtualMailman You'll probably have a little trouble finding your way if you don't read french though. :) Babelfish might help, haven't tried. ---------------------------------------------------------------------- Comment By: Paul Hampson (tbble) Date: 2006-04-22 21:48 Message: Logged In: YES user_id=87909 Crud, wrapping... The changes are all on one line. ---------------------------------------------------------------------- Comment By: Paul Hampson (tbble) Date: 2006-04-22 21:47 Message: Logged In: YES user_id=87909 minfrin, create it as listname-domain or try this patch: diff -urNad mailman-2.1.5/Mailman/Cgi/create.py /tmp/dpep.bPHYjm/mailman-2.1.5/Mailman/Cgi/create.py --- mailman-2.1.5/Mailman/Cgi/create.py 2006-04-22 20:58:10.324872941 +1000 +++ /tmp/dpep.bPHYjm/mailman-2.1.5/Mailman/Cgi/create.py 2006-04-22 21:13:31.596133649 +1000 @@ -184,7 +184,7 @@ oldmask = os.umask(002) try: try: - mlist.Create(listname, owner, pw, langs, emailhost) + mlist.Create("%s@%s" % (listname,hostname), owner, pw, langs, emailhost) finally: os.umask(oldmask) except Errors.EmailAddressError, s: Which will add the '@domain' to the listname before passing it to mlist.Create, which the patch changes to deal with '@' the way we want. ---------------------------------------------------------------------- Comment By: Graham Leggett (minfrin) Date: 2006-03-18 07:39 Message: Logged In: YES user_id=129704 I tried the patch at http://al.blog.free.fr/mailman/mailman-vh-2.1.5.patch and it applied cleanly to mailman as provided by RHEL4. I tried to create a list called "list(a)domain1.com", but this failed with the error "Error: List name must not include "@"". Does this patch have any sort of instructions anywhere? ---------------------------------------------------------------------- Comment By: Arnaud Lavrard (arnaudlavrard) Date: 2005-07-20 23:52 Message: Logged In: YES user_id=1315788 I ported the patch to mailman 2.1.5 : http://al.blog.free.fr/mailman/mailman-vh-2.1.5.patch ---------------------------------------------------------------------- Comment By: The Anarcat (anarcat) Date: 2005-03-17 07:40 Message: Logged In: YES user_id=246797 I have ported the patch to 2.1.4, no news on 2.1.5 yet. I have also put the patch in a seperate CVS server. Fetch all the goods there: http://cvs.koumbit.net/cgi-bin/cvsweb/koumbit-maint/patches/mailman-true-vi… http://cvs.koumbit.net/cgi-bin/cvsweb/koumbit-maint/patches/mailman-true-vi… I've also updated the 2.1.1 patch to fix the list-id, so I delete the attachment, fetch the patch straight from our CVS for the latest fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=943827&group_i…

1 0

[ mailman-Patches-943827 ] true virtual hosting patch for 2.1
by SourceForge.net 22 Apr '06

22 Apr '06

Patches item #943827, was opened at 2004-04-29 02:57 Message generated for change (Comment added) made by tbble You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=943827&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: The Anarcat (anarcat) Assigned to: Nobody/Anonymous (nobody) Summary: true virtual hosting patch for 2.1 Initial Comment: [copy of the mail sent to -developpers@] We developped a reliable solution for running lists with the same name on different domains on the same Mailman installation. I implemented that on top of the Mailman 2.1.1-5.1 Debian stable package. All that is needed is to patch 2 files (bin/newlist, Mailman/MailList.py) in the mailman install, and here is the patch: http://bugs.koumbit.net/file_download.php?file_id=3&type=bug There's only one caveat right now: Mailman/Cgi/create.py might need to get patched too, but I haven't got around looking at it yet, and it "just works", for now. I don't know what's the current status of virtual hosting support on Mailman, but this patch is a simple hack that should bring joy in the homes of all Mailman admins around the world. :) I got my inspiration and part of the code from: http://mithrandr.moria.org/blog/139.html All it does is to add the domain to the internal_name() of a list. The real_name is kept as is, and the getListAddress() does the Right Thing. This makes Mailman generate aliases like: list-example.com: "|/var/lib/mailman/mail/mailman post list-example.com" Care will have to be taken on the MTA side to map those list-example.com to list(a)example.com. We are using alternc.org to manage our server, so we are using LDAP, so everything went pretty smoothly. :) But I guess it will require some magic on the Postfix side or something... Cheers, A. PS: for those wanting to see more, you can come to our Wiki: http://koumbit.net/wiki/VirtualMailman You'll probably have a little trouble finding your way if you don't read french though. :) Babelfish might help, haven't tried. ---------------------------------------------------------------------- Comment By: Paul Hampson (tbble) Date: 2006-04-22 21:47 Message: Logged In: YES user_id=87909 minfrin, create it as listname-domain or try this patch: diff -urNad mailman-2.1.5/Mailman/Cgi/create.py /tmp/dpep.bPHYjm/mailman-2.1.5/Mailman/Cgi/create.py --- mailman-2.1.5/Mailman/Cgi/create.py 2006-04-22 20:58:10.324872941 +1000 +++ /tmp/dpep.bPHYjm/mailman-2.1.5/Mailman/Cgi/create.py 2006-04-22 21:13:31.596133649 +1000 @@ -184,7 +184,7 @@ oldmask = os.umask(002) try: try: - mlist.Create(listname, owner, pw, langs, emailhost) + mlist.Create("%s@%s" % (listname,hostname), owner, pw, langs, emailhost) finally: os.umask(oldmask) except Errors.EmailAddressError, s: Which will add the '@domain' to the listname before passing it to mlist.Create, which the patch changes to deal with '@' the way we want. ---------------------------------------------------------------------- Comment By: Graham Leggett (minfrin) Date: 2006-03-18 07:39 Message: Logged In: YES user_id=129704 I tried the patch at http://al.blog.free.fr/mailman/mailman-vh-2.1.5.patch and it applied cleanly to mailman as provided by RHEL4. I tried to create a list called "list(a)domain1.com", but this failed with the error "Error: List name must not include "@"". Does this patch have any sort of instructions anywhere? ---------------------------------------------------------------------- Comment By: Arnaud Lavrard (arnaudlavrard) Date: 2005-07-20 23:52 Message: Logged In: YES user_id=1315788 I ported the patch to mailman 2.1.5 : http://al.blog.free.fr/mailman/mailman-vh-2.1.5.patch ---------------------------------------------------------------------- Comment By: The Anarcat (anarcat) Date: 2005-03-17 07:40 Message: Logged In: YES user_id=246797 I have ported the patch to 2.1.4, no news on 2.1.5 yet. I have also put the patch in a seperate CVS server. Fetch all the goods there: http://cvs.koumbit.net/cgi-bin/cvsweb/koumbit-maint/patches/mailman-true-vi… http://cvs.koumbit.net/cgi-bin/cvsweb/koumbit-maint/patches/mailman-true-vi… I've also updated the 2.1.1 patch to fix the list-id, so I delete the attachment, fetch the patch straight from our CVS for the latest fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=943827&group_i…

1 0

[ mailman-Feature Requests-1472242 ] search user subscription lists
by SourceForge.net 21 Apr '06

21 Apr '06

Feature Requests item #1472242, was opened at 2006-04-18 04:58 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1472242&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Works For Me Priority: 5 Submitted By: alcarobe (alcarobe) Assigned to: Nobody/Anonymous (nobody) Summary: search user subscription lists Initial Comment: mailman now allows to find all or a dedicated mailing list another useful search facility should be added to allow people to find all the lists where they are subscribed to ---------------------------------------------------------------------- Comment By: alcarobe (alcarobe) Date: 2006-04-20 05:03 Message: Logged In: YES user_id=1504579 the "List my other subscriptions" search was indeed what I was looking for, thanks for the fast reply ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-18 12:16 Message: Logged In: YES user_id=1123998 If you are asking for something other that the "List my other subscriptions" search that currently exists on the user options page, please clarify what it is you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1472242&group_…

1 0

[ mailman-Feature Requests-1474203 ] A junk Mail button would be great
by SourceForge.net 21 Apr '06

21 Apr '06

Feature Requests item #1474203, was opened at 2006-04-21 09:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1474203&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Narishkup (mikekatz) Assigned to: Nobody/Anonymous (nobody) Summary: A junk Mail button would be great Initial Comment: I would love a junk mail button in the administrators review of defered messages section. That button would with one click delete the message and put the senders domain on the rejected domain list. Currently it is a 4 click proccess to put each ban people but domains are even harder to restrict. This should be a button in addition to the existing choices so that less drastic action could also be taken. Thanks so mucch fo a great product. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1474203&group_…

1 0

[ mailman-Feature Requests-1472242 ] search user subscription lists
by SourceForge.net 20 Apr '06

20 Apr '06

Feature Requests item #1472242, was opened at 2006-04-18 11:58 Message generated for change (Comment added) made by alcarobe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1472242&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Open Resolution: None Priority: 5 Submitted By: alcarobe (alcarobe) Assigned to: Nobody/Anonymous (nobody) Summary: search user subscription lists Initial Comment: mailman now allows to find all or a dedicated mailing list another useful search facility should be added to allow people to find all the lists where they are subscribed to ---------------------------------------------------------------------- >Comment By: alcarobe (alcarobe) Date: 2006-04-20 12:03 Message: Logged In: YES user_id=1504579 the "List my other subscriptions" search was indeed what I was looking for, thanks for the fast reply ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-18 19:16 Message: Logged In: YES user_id=1123998 If you are asking for something other that the "List my other subscriptions" search that currently exists on the user options page, please clarify what it is you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1472242&group_…

1 0

[ mailman-Patches-1442025 ] List Specialisation for Support Groups
by SourceForge.net 20 Apr '06

20 Apr '06

Patches item #1442025, was opened at 2006-03-02 20:32 Message generated for change (Comment added) made by ppsys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1442025&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: List Specialisation for Support Groups Initial Comment: This patch modifies Mailman to address the following scenario: 1. A Mailman list to be used as the means by which a closed set of list subcribers (support staff) can provide responses to requests for support made by non-subscribers (customers) posting messages to the list. 2. Requirement that the incoming posts from customers (both original and follow up) and consequential responses from support staff should be entirely list-centric: a. The customer should see the response to a posting to the list as coming from the list, not the support person that responded. b. Any subsequent reply by the customer to a message from the list should go back to the list. c. Replies to customers by support staff should automatically be distributed to the the list. d. This should all happen by use of the basic features of typical MUAs by both support staff and customers; use of the MUA GUI's "Reply" button should do all that is necessary. e. Using the list in the way described should require no or minimal explanation to support staff and absolutely no explanation to customers. f. The e-mail addresses of support staff should remain hidden behind the list address. For more detail of implementation see: http://www.openinfo.co.uk/mm/patches/supportlist/index.html ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2006-04-20 06:15 Message: Logged In: YES user_id=75166 Use response-2.1.7-0.1.patch.gz for both MM 2.1.7 and MM 2.1.8 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1442025&group_…

1 0

[ mailman-Bugs-1256272 ] NNTP gatewaying trashes Message-IDs
by SourceForge.net 20 Apr '06

20 Apr '06

Bugs item #1256272, was opened at 2005-08-10 16:47 Message generated for change (Comment added) made by nobrowser You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1256272&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: nntp/news Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Kate Turner (kateturner) Assigned to: Nobody/Anonymous (nobody) Summary: NNTP gatewaying trashes Message-IDs Initial Comment: when a message is relayed to NNTP, the NewsRunner unconditionally replaces the existing Message-ID with its own. this breaking threading when reading a list via news, and when an NNTP user replies to a list message. a better solution would be either: 1) do not rewrite the message-id unless the NNTP server reports an error when posting it (duplicate ID); or 2) optionally, always rewrite posters' message-ids into a mailman-generated ID, and use this ID for both mail and news. i have implemented the former at our site and it appears to work, but it's so ugly i'd not feel comfortable submitting a patch for it. ---------------------------------------------------------------------- Comment By: Ian Z. (nobrowser) Date: 2006-04-19 22:13 Message: Logged In: YES user_id=1192798 Finally! I thought I was the only one who noticed this. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346413 Why would the mail message-id ever cause a conflict with the NNTP server? message-ids are supposed to be globally unique and there is a convention (in RFC 2822?) that ensures it (put in the FQDN and something unique to the generating software). So I think 1) is not ugly but correct :) 2) wouldn't completely solve the problem. I can post one copy of a message to a mailman list and another directly to another recipient, including myself. (I actually Cc myself on all mail I send). If mailman does 2), the extra recipient will still be confused. Ian ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1256272&group_…

1 0

[ mailman-Patches-820723 ] Mailman/pipermail/MHonArc integration patch
by SourceForge.net 19 Apr '06

19 Apr '06

Patches item #820723, was opened at 2003-10-09 16:19 Message generated for change (Comment added) made by ppsys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=820723&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pipermail Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman/pipermail/MHonArc integration patch Initial Comment: This patch tightly integrates the MHonArc mail-to-HTML convertor with Mailman and its internal pipermail archiving code. The purpose of the patch is to produce a fusion of (hopefully) the best features of pipermail and MHonArc for handling Mailman mailing list archives. For more detail see patch content or http://www.openinfo.co.uk/mailman/patches/mhonarc/index.html ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2006-04-19 23:01 Message: Logged In: YES user_id=75166 Use mhonarc-2.1.7-0.1.patch.gz for both MM 2.1.7 and MM 2.1.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2006-03-02 21:17 Message: Logged In: YES user_id=75166 mhonarc-2.1.6-0.3.patch.gz corrects a long standing omission in the code of Mailman/Cgi/create.py which fails to get the initial setup of lists created through the web quite right. This leads to spurious errors being logged on message archiving until bin/arch --wipe is run for such a list affected. Lists created with bin/newlist did not have this problem. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2005-09-23 21:45 Message: Logged In: YES user_id=75166 mhonarc-2.1.6-0.2.patch.gz corrects an error in the modified code of $prefix/bin/arch introduced by the mhonarc-2.1.6-0.1.patch.gz - the problem was not present in patches for previous MM versions. In some circumstances, after running $prefix/bin/arch --wipe, subsequent post to a list my be generated using the wrong archiver. Examining index pages in the archives of a list will show if this problem has affected that list. Reinstallation with this revised patch and rerunning $prefix/bin/arch --wipe should resolve the problem. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2005-08-23 17:43 Message: Logged In: YES user_id=75166 mhonarc-2.1.6-0.1.patch.gz is a MM 2.1.6 compatible version of the patch ---------------------------------------------------------------------- Comment By: dfragos (dfragos) Date: 2005-07-21 15:24 Message: Logged In: YES user_id=1310569 what about MM 2.1.6? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2004-08-03 10:04 Message: Logged In: YES user_id=75166 mhonarc-2.1.5-0.1.patch.gz is a MM 2.1.5 compatible version of the patch ---------------------------------------------------------------------- Comment By: Martin Mokrejs (mmokrejs) Date: 2004-04-19 23:53 Message: Logged In: YES user_id=696559 I've applied this patch(mhonarc-2.1.4-0.1.patch.gz) and it works great for me. Would someone apply to offcial cvs tree? Thanks. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2004-01-02 15:32 Message: Logged In: YES user_id=75166 mhonarc-2.1.4-0.1.patch is a MM 2.1.4 compatible version of this patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-10-22 14:32 Message: Logged In: YES user_id=75166 mhonarc-2.1.3-0.6.patch better supports the use of MHonArc -saveresources option. Also fixes minor HTML syntax error in mhonarc.mrc and author.mrc that affected generated date and author index pages. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-10-14 05:49 Message: Logged In: YES user_id=75166 With mhonarc-2.1.3-0.4.patch, the default path to MHonArc itself defined in Defaults.py is the empty string and, until this is changed, the option to select MHonArc instead of pipermail for per-list archiving is not offered on the web admin GUI. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-10-10 17:51 Message: Logged In: YES user_id=75166 Under some circumstances, when a single message is passed to MHonArc for archiving via a pipe, MHonArc may finish its processing and exit, closing its STDIN before the Mailman process that invoked it has finished output of the message to the pipe. Mistakenly, the patched pipermail code treated this as an error. mhonarc-2.1.3-0.3.patch corrects this mistake. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=820723&group_i…

1 0

[ mailman-Patches-760567 ] moderation request message content
by SourceForge.net 19 Apr '06

19 Apr '06

Patches item #760567, was opened at 2003-06-25 15:25 Message generated for change (Comment added) made by ppsys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=760567&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: moderation request message content Initial Comment: This patch makes per-list configurable the inclusion of the body of messages that require moderation in the request messages sent to list moderators. This patch has similar objectives to those of patch #593674 but is a simpler implementation. This adds one list attribute, which can be set or unset via the web admin GUI, and which controls whether the moderated message body is included in the moderator request. Apply the attached patch file with the MM build directory as the current working directory using the command: patch -p1 < path-to-patch-file ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2006-04-19 22:59 Message: Logged In: YES user_id=75166 Use modinc-2.1.7-0.1.patch for both MM 2.1.7 and MM 2.1.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2005-08-23 17:41 Message: Logged In: YES user_id=75166 modinc-2.1.6-0.1.patch is a MM 2.1.6 compatible version of the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2004-08-03 10:02 Message: Logged In: YES user_id=75166 modinc-2.1.5-0.1.patch is a MM 2.1.5 compatible version of the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2004-01-02 15:28 Message: Logged In: YES user_id=75166 modinc-2.1.4-0.1.patch is a MM 2.1.4 compatible veriosn of this patch ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-12-24 17:29 Message: Logged In: YES user_id=12800 I'm going to defer this one until 2.1.5 since I don't want to add any new list attributes at this late date. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-09-30 20:43 Message: Logged In: YES user_id=75166 modinc-2.1.3-0.1.patch is a MM 2.1.3 compatible version of the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-06-25 17:21 Message: Logged In: YES user_id=75166 Missed one changed file from initial patch ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=760567&group_i…

1 0

[ mailman-Patches-644797 ] Revised mailer exit status
by SourceForge.net 19 Apr '06

19 Apr '06

Patches item #644797, was opened at 2002-11-27 15:56 Message generated for change (Comment added) made by ppsys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=644797&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 5 Submitted By: Richard Barrett (ppsys) Assigned to: Nobody/Anonymous (nobody) Summary: Revised mailer exit status Initial Comment: This patch modifies the Python scripts in $prefix/scripts/ that are used by the MTA to deliver incoming mail to Mailman. The exit statuses now returned are drawn from the mail related values defined in /usr/include/sysexits.h This allows the MTA to return more meaningful responses to the sender when rejecting mail. It also allows a more sympathetic treatment of mail in the event that the Python script suffers an unexpected exception when handling incoming email. Such exceptions are now logged to MM's $prefix/logs/erro in all but the most extreme error cases and the internal information about the Python exception is not passed into the response to the sender. There are two patch versions; one for MM 2.0.13 and the other for MM 2.1b5 in the MM build directory say: patch -p1 < patch-filename ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2006-04-19 22:55 Message: Logged In: YES user_id=75166 Use exitstatus-2.1.7-0.1.patch.gz for both MM 2.1.7 and MM 2.1.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2005-08-23 17:46 Message: Logged In: YES user_id=75166 exitstatus-2.1.6-0.1.patch.gz is a MM 2.1.6 compatible version of the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2004-08-03 09:56 Message: Logged In: YES user_id=75166 exitstatus-2.1.5-0.1.patch.gz is a MM 2.1.5 compatible version of the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2004-01-02 15:14 Message: Logged In: YES user_id=75166 exitstatus-2.1.3-0.1.patch can be used with MM 2.1.4 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-09-30 20:39 Message: Logged In: YES user_id=75166 exitstatus-2.1.3-0.1.patch is a MM 2.1.3 compatible version of the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-04-28 14:40 Message: Logged In: YES user_id=75166 exitstatus-2.1.2-0.1.patch is a revision of the patch for MM 2.1.2 compatibility ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-02-10 11:42 Message: Logged In: YES user_id=75166 exitstatus-2.1-0.1.patch is alos applicable to MM release 2.1.1 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-01-02 16:30 Message: Logged In: YES user_id=75166 exitstatus-2.1-0.1.patch is a revision of the patch for MM 2.1 compatibility ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-24 03:29 Message: Logged In: YES user_id=12800 Sorry Richard, I have to defer this one. It's too much for me to think about for MM2.1. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-12-11 11:58 Message: Logged In: YES user_id=75166 exitstatus-2.1b6-0.1.patch is a revision of the patch for MM 2.1b6 compatibility ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-11-27 15:58 Message: Logged In: YES user_id=75166 version for MM 2.1b5 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=644797&group_i…

1 0

[ mailman-Patches-444884 ] Integration of Mailman and htdig for archiving
by SourceForge.net 19 Apr '06

19 Apr '06

Patches item #444884, was opened at 2001-07-26 18:27 Message generated for change (Comment added) made by ppsys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Unofficial 2.0 patch Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 3 Submitted By: Richard Barrett (ppsys) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Integration of Mailman and htdig for archiving Initial Comment: This patch is applicable to Mailman 2.0.6 release that has had search enhancement patch 444879 patch installed - if your Defaults.py has the ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in it then you've got that patch. It replaces earlier patches 401670 and 402423 and is mainly to correct some problems arising from fixes introduced into Mailman by bug fix releases since the 402423 patch. This patch integrates htdig with Mailman and provides: 1. per list search facility with a search form on the list's TOC page. 2. maintenance of privacy of private archives which requires the user to establish their credentials via the normal private archive access before any access via htdig is allowed. 3. a common base URL for both public and private archive access via htsearch results so that htdig indices are unaffected by changingan archive from private to public and vice versa. All access to archives via htdig is controlled by a new wrapped cgi- bin script called htdig.py. 4. a new cron activated script and extra crontab entry which runs htdig regularly to maintain the per list search indices. 5. automatic creation, deletion and maintenance of htdig configuration files and such. Beyond installing htdig and telling Mailman where it is via mm_cfg you do not have to do any other setup. Well not quite you do have to set up a single per installation symlink to allow htdig to find the automatically generated per list htdig configuration files. You probably want to run this patch as follows: cd <mailman 2.0.6 untarred and unzipped directory> patch -p1 < <this patch file> ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2006-04-19 22:53 Message: Logged In: YES user_id=75166 Use htdig-2.1.7-0.1.patch.gz for both MM 2.1.7 and MM 2.1.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2005-08-23 17:38 Message: Logged In: YES user_id=75166 htdig-2.1.6-0.1.patch.gz is a MM 2.1.6 compatible version of the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2004-08-03 09:45 Message: Logged In: YES user_id=75166 htdig-2.1.5-0.1.patch.gz is a MM 2.1.5 compatible version of the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2004-01-03 09:16 Message: Logged In: YES user_id=75166 htdig-2.1.4-0.1.patch is a MM 2.1.4 compatible version of the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-12-15 16:13 Message: Logged In: YES user_id=75166 htdig-2.1.3-0.5.patch modifies htdig.py and private.py; the security changes introduced by htdig-2.1.3-0.2 patch to these scripts incorrectly blocked access to the listname.mbox/listname.mbox file. The 0.5 revision of the patch corrects this error. This problem and a suggested fix were pointed out to me in a private email by Stephan Berndts stb-mm at spline.de ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-10-22 14:55 Message: Logged In: YES user_id=75166 htdig-2.1.3-0.4.patch provides minor improvements in handling of HTTP request handled by htidg.py which lead to the user receiving an authentication challenge. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-10-19 21:13 Message: Logged In: YES user_id=75166 htdig-2.1.3-0.3.patch.gz add minor private archive security improvements to the patch for MM 2.1.3 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-09-30 20:14 Message: Logged In: YES user_id=75166 htdig-2.1.3-0.1.patch is a MM 2.1.3 compatible version of the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-06-06 17:47 Message: Logged In: YES user_id=75166 last comment should have read: htdig-2.1.2-0.4.patch.gz corrects an error in 2 scripts, mmsearch.py and remote_mmsearch, which caused an exception if list archives were being accessed via HTTPS and a search was performed. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-06-06 17:45 Message: Logged In: YES user_id=75166 htdig-2.1.2-0.3.patch.gz corrects an error in 2 scripts, mmsearch.py and remote_mmsearch, which caused an exception if list archives were being accessed via HTTPS and a search was performed. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-05-01 19:00 Message: Logged In: YES user_id=75166 htdig-2.1.2-0.3.patch.gz adds some minor performance improvement in template handling in MM 2.1.2 You should consider also applying this bug-fis patch: [ 730769 ] template access hierarchy is broken http://sourceforge.net/tracker/index.php? func=detail&aid=730769&group_id=103&atid=100103 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-04-28 15:44 Message: Logged In: YES user_id=75166 htdig-2.1.2-0.2.patch.gz corrects error in file uploaded as htdig-2.1.2-0.1.patch.gz. Sorry for any inconvenience. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-04-28 14:46 Message: Logged In: YES user_id=75166 htdig-2.1.2-0.1.patch.gz is a revised version for MM 2.1.2 compatibility. It also incoporates a previosuly unpublished change to overcome a potential problem with htdig excluced urls - see the INSTALL.htdig-mm file for more information ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-03-21 18:29 Message: Logged In: YES user_id=75166 htdig-2.1.1-0.4.patch.gz fixes a problem with mmsearch handling multi-page search results from htsearch. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-03-21 17:54 Message: Logged In: YES user_id=75166 htdig-2.1.1-0.3.patch.gz fixes a fault when mmsearch.py is rasing an excpetion because it has had a problem running htsearch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-03-20 14:10 Message: Logged In: YES user_id=75166 htdig-2.1.1-0.2.patch.gz close a security exploit which allows leakage of information held in htdig's per-list search indexes to users not authorized to view private list archives. Read file INSTALL.htdig-mm installed by this patch for details and instructions for upgrading MM installations using earlier versions of this patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-02-10 15:50 Message: Logged In: YES user_id=75166 htdig-2.1.1-0.1.patch.gz introduces no functional change but applies without offset warnings to MM 2.1.1 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-02-05 18:12 Message: Logged In: YES user_id=75166 It seems it is possible, if this patch is installed, for a list's htdig conf file and the list specific htdig index db files to be read directly through the web interface for list archives. Even if this patch isn't installed it seems a list's pipermail.pck file can also be read directly through the web interface for list archives. This seems to be true for accesses via /pipermail for public lists and via /mailman/private for private lists. The problem does not occur for htdig search results accessed via /mailman/htdig as the htdig.py script is more protective than private.py Broadly speaking the data affected is availble to a user in normal operation which is why I do not consider the issue to be a security breach as such. Adding the following RewriteRule to Apache's httpd.conf prevents the situation, assuming you got the RewriteEngine On: RewriteRule ^(/pipermail/.*)/(pipermail.pck|htdig/[^/]*)$ $1/index.html [F] RewriteRule ^(/mailman/private/.*)/(pipermail.pck|htdig/[^/]*)$ $1/index.htm l [F] You could, of course, substitute an R flag for the F flag on the RewriteRules and be more hacker friendly. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-01-22 14:20 Message: Logged In: YES user_id=75166 htdig-2.1-0.3.patch corrects yet another bug in htdig.py. Hope that all of them! Stops use of obsolete config variable DEFAULT_HOST in several files. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-01-15 20:18 Message: Logged In: YES user_id=75166 htdig-2.1-0.2.patch corrects a bug in htdig.py and deals with an adverse interaction between htdig.py and a bug in $prefix/scripts/driver (see #668685 for a patch to fix this). It also improves the content type and security handling by htdig.py for MM 2.1 version of patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-01-15 20:14 Message: Logged In: YES user_id=75166 Uploaded wrong file mailer-2.0.13-0.4.patch on last attempt. Should have been htdig-2.0.13-0.4.patch which improves the content type and security handling by htdig.py for MM 2.0.13 version of patch. Please ignore mailer-2.0.13-0.4.patch file ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-01-15 20:09 Message: Logged In: YES user_id=75166 mailer-2.0.13-0.4.patch improves the content type and security handling by htdig.py for MM 2.0.13 version of patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-01-02 16:07 Message: Logged In: YES user_id=75166 htdig-2.1-0.1.patch is a revised version of the patch that is compatible with MM 2.1 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-12-11 11:48 Message: Logged In: YES user_id=75166 htdig-2.1b6-0.1.patch is a revised version of the patch that is compatible with MM 2.1b6 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-12-04 10:53 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.3.patch corrects a minor typo in text appearing in the list TOC after the patch is applied. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-11-27 10:24 Message: Logged In: YES user_id=75166 htdig-2.1b5-0.1.patch is a revised version of the patch that is compatible with MM 2.1b5 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-10-30 11:43 Message: Logged In: YES user_id=75166 htdig-2.1b4-0.1.patch is a revised version of the patch that is compatible with MM 2.1b4 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-10-14 11:50 Message: Logged In: YES user_id=75166 htdig-2.1b3-0.3.patch removes use of the file() function, used instead of the open() function, in three cron scripts added by the patch. Use of the file() function created an unnecessary dependency on Python 2.2 ---------------------------------------------------------------------- Comment By: Colin Mackinlay (cmackinlay) Date: 2002-10-12 16:51 Message: Logged In: YES user_id=624179 Got a workaround! The line referred to in the traceback: file(rundig_run_file, 'w').close() is used to create a 'rundig_last_run' file of lenght 0 bytes Creating this manually (or copying it) means the line isn't called and everything seems to work. Either file() is not a valid function call or my python is broken - I'm not literate enough in python to know the answer though! ---------------------------------------------------------------------- Comment By: Colin Mackinlay (cmackinlay) Date: 2002-10-06 14:18 Message: Logged In: YES user_id=624179 Just rebuilt MM as 2.1b3 with htdig. Upgraded lists which had htdig before work fine New lists give the obvious error: Unable to read word database file Did you run htmerge? Running the cronjob doesn't fix as it used to, message is: Output from command /usr/bin/python - S /usr/local/mailman/cron/nightly_htdig .. Traceback (most recent call last): File "/usr/local/mailman/cron/nightly_htdig", line 153, in ? main() File "/usr/local/mailman/cron/nightly_htdig", line 118, in main file(rundig_run_file, 'w').close() NameError: global name 'file' is not defined The archive/htdig folder only contains the xx.conf file, but no db.xx files If I copy in db.xx files from another list then the problem goes away (except I've now got an invalid set of references!) Is this my elementary error or is it more sinister?! ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-15 11:02 Message: Logged In: YES user_id=75166 htdig-2.1b3-0.2.patch corrects a dumb syntax error in htdig- 2.1b3-0.1.patch which will typically show up as logged errors in the operation of the ArchRunner qrunner at line 721 of HyperArch.py ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-14 16:51 Message: Logged In: YES user_id=75166 htdig-2.1b3-0.1.patch is a revised version of the patch that is compatible with MM 2.1b3 ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 16:33 Message: Logged In: YES user_id=12800 I've sent Richard some comments off-line about this patch. Meta comments: the 2.0.x patches can't be officially supported, but I'm going to create an unofficial patches page off the wiki for where the 2.0 patches can be migrated. I think this patch set is too big for MM2.1, but if it's cleaned up as per my private message, let's re-evaluate it for MM2.2 (or 3.0). ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-05 10:11 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.2.patch just adds a GPL notice to the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-01 16:35 Message: Logged In: YES user_id=75166 htdig-2.1b2-0.1.patch is a revised version of the patch that is compatible with MM 2.1b2 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:25 Message: Logged In: YES user_id=75166 htdig-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 15:07 Message: Logged In: YES user_id=75166 Do not use htdig-2.0.12-0.1.patch there is an error in it. Use htdig-2.0.12-0.2.patch instead ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:10 Message: Logged In: YES user_id=75166 htdig-2.0.12-0.1.patch is a revised version of the patch that applies without complaint to MM 2.0.12. It also add a facility for adding site wide htdig configuration attributes to all list specific htdig configuration files. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:59 Message: Logged In: YES user_id=75166 htdig-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 This version removes an incompatibility with Python 2.2 which caused warning messages to be generated when any of the family cron/nightly_htdig scripts were run. Some guidance on file access permissions for some htdig database files needed by rundig have been added to installation notes. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:59 Message: Logged In: YES user_id=75166 htdig-2.0.10-0.1.patch is a revised version of the patch that is compatible with MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:46 Message: Logged In: YES user_id=75166 htdig-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:22 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002 Known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:56 Message: Logged In: YES user_id=75166 htdig-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:58 Message: Logged In: YES user_id=75166 htdig-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. The only known deficiency is that the non-English versions of files under $build/templates still contain text in English and need translations I cannot do. Also the necessary pygettext activity and subsequent translations in files under $build/messages remain to be done. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 17:33 Message: Logged In: YES user_id=75166 The htdig-2.0.8-0.1.patch version of the patch resolves a problem that can arise with htdig indexing if the web_page_url for a list uses other than the http addressing (some folks want to use https). While specified as for MM 2.0.8 the revised patch should work OK with 2.0.7, 2.0.6 and probably back as far as 2.0.3. If you do not have the requirement for using other than http addressing in you lists web_page_urls it probably isn't worth the trouble of upgrading to this patch level. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:08 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:00 Message: Logged In: YES user_id=75166 This patch should also apply without problems to Mm 2.0.7 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-09 11:54 Message: Logged In: YES user_id=75166 The htdig-2.0.6-03.patch version of the patch makes some previously hard-coded things configurable and enhances the capability to run the htdig searches and indexing on a different machine to the one delivering Mailman and Mailman's web UI. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444884&group_i…

1 0

[ mailman-Patches-444879 ] Archive indexer control to improve index
by SourceForge.net 19 Apr '06

19 Apr '06

Patches item #444879, was opened at 2001-07-26 18:01 Message generated for change (Comment added) made by ppsys You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Pipermail Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 3 Submitted By: Richard Barrett (ppsys) Assigned to: Barry A. Warsaw (bwarsaw) Summary: Archive indexer control to improve index Initial Comment: This patch is applicable to Mailman 2.0.6 release and supercedes ealier patches 401669 and 402422. This patch should improve the quality of search results returned by search engines such as htdig (http://www.htdig.org) where the seach engine's index builder responds to strings embedded in the html pages that are the subject of the indexing. The changes in this patch: 1. allow strings for enabling and disabling indexing to be defined in mm_cfg.py. 2. embeds those strings in the pages generated as the html version of a list's archive. By default nothing in the html changes. To get the desired effect, you must define ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE in mm_cfg.py You probably want to run this patch as follows: cd <mailman 2.0.6 untarred and unzipped directory> patch -p1 < <this patch file> See also the associated patch for integrating the htdig search software with mailman's internal archiver ouput. ---------------------------------------------------------------------- >Comment By: Richard Barrett (ppsys) Date: 2006-04-19 22:49 Message: Logged In: YES user_id=75166 Use indexing-2.1.7-0.1.patch.gz for both MM 2.1.7 and MM 2.1.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2005-08-23 17:36 Message: Logged In: YES user_id=75166 indexing-2.1.6-0.1.patch.gz is a MM 2.1.6 compatible version of the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2004-08-03 09:39 Message: Logged In: YES user_id=75166 indexing-2.1.5-0.1.patch.gz is a MM 2.1.5 compatible version of the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2004-01-03 09:20 Message: Logged In: YES user_id=75166 indexing-2.1.4-0.1.patch is a MM 2.1.4 compatible version of the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-09-30 20:10 Message: Logged In: YES user_id=75166 indexing-2.1.3-0.1.patch is a MM 2.1.3 compatible version of the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-04-28 14:37 Message: Logged In: YES user_id=75166 indexing-2.1.2-0.1.patch.gz no longer needs patch #661138 to be applied as that patch was incorporated in the MM 2.1.2 release ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-04-28 14:34 Message: Logged In: YES user_id=75166 indexing-2.1.2-0.1.patch.gz is revised for MM 2.1.2 compatibility. Before applying thisversion of the patch you must also apply Bug fix patch #728836 to the source distribution ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-02-10 15:49 Message: Logged In: YES user_id=75166 indexing-2.1.1-0.1.patch.gz introduces no functional change but applies without offset warnings to MM 2.1.1 Before applying this patch to the MM 2.1 source distribution you must apply patch 661138 (corrects defects in some HTML templates) to the distribution ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2003-01-02 16:05 Message: Logged In: YES user_id=75166 indexing-2.1-0.1.patch is a revised version of the patch that is compatible with MM 2.1. Before applying this patch to the MM 2.1 source distribution you must apply patch 661138 (corrects defects in some HTML templates) to the distribution ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-12-11 11:55 Message: Logged In: YES user_id=75166 indexing-2.1b6-0.1.patch is a revised version of the patch that is compatible with MM 2.1b6 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-12-11 11:53 Message: Logged In: YES user_id=75166 indexing-2.1b6-0.1.patch is a revised version of the patch that is compatible with MM 2.1b6 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-12-11 11:52 Message: Logged In: YES user_id=75166 indexing-2.1b6-0.1.patch is a revised version of the patch that is compatible with MM 2.1b6 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-11-27 10:22 Message: Logged In: YES user_id=75166 indexing-2.1b5-0.1.patch is a revised version of the patch that is compatible with MM 2.1b5 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-10-30 11:40 Message: Logged In: YES user_id=75166 indexing-2.1b4-0.1.patch is a revised version of the patch that is compatible with MM 2.1b4 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-10-30 11:39 Message: Logged In: YES user_id=75166 indexing-2.1b4-0.1.patch is a revised version of the patch that is compatible with MM 2.1b4 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-14 16:46 Message: Logged In: YES user_id=75166 indexing-2.1b3-0.1.patch is a revised version of the patch that is compatible with MM 2.1b3 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-08 17:32 Message: Logged In: YES user_id=75166 An additional file, README.NOINDEXtags is added to indexing-2.0.13-0.3.patch version that discusses the issue of what tags to use for controlling various search engine indexers. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-08 17:19 Message: Logged In: YES user_id=75166 An error when building the indexing-2.1b2-0.1.patch meant that copies of the originals of two of the files modified by this version of the patch were added when the patch was run. indexing-2.1b2-0.1.patch removes this error. However, the original error is benign and can be corrected by deleting the extra files HyperArch.py.orig and Defaults.py.in.orig. An additional file, README.NOINDEXtags is added that discusses the issue of what tags to use for controlling various search engine indexers. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 14:19 Message: Logged In: YES user_id=12800 Another question: is there no standard (de-facto or otherwise) for generic markup that tells indexers not to index a particular section? IOW, for ARCHIVE_INDEXING_ENABLE and ARCHIVE_INDEXING_DISABLE, is there some generic value that would instruct most (all?) indexers to ignore that section? Or does it necessarily have to be indexer specific? I'm thinking of the situation where you might have ht://Dig installed locally, but your archives are still being spidered by external indexers. It would be good if something more generic could be added to Defaults.py.in ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-08-08 14:14 Message: Logged In: YES user_id=12800 Looking at the 2.1b2 patch, why does it try to create HyperArch.py.orig and Defaults.py.in.orig? Are those included in the patch by mistake? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-05 10:08 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.2.patch just adds a GPL notice to the patch ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-08-01 16:33 Message: Logged In: YES user_id=75166 indexing-2.1b2-0.1.patch is a revised version of the patch that is compatible with MM 2.1b2 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-30 11:23 Message: Logged In: YES user_id=75166 indexing-2.0.13-0.1.patch is purely cosmetic to get no mumble application to MM 2.0.13 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-07-25 14:11 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch should apply without problems to MM 2.0.12 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-05-23 09:50 Message: Logged In: YES user_id=75166 indexing-2.0.11-0.1.patch is a revised version of the patch that is compatible with MM 2.0.11 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-19 10:53 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch should apply without problems to MM 2.0.10 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-04-08 17:43 Message: Logged In: YES user_id=75166 indexing-2.0.9-0.1.patch is a revised version of the patch that is compatible with MM 2.0.9 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2002-03-06 16:14 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20020306.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 12:30 GMT 6 Mar 2002. Corrects problem noted or 5 Mar 2002 by nobody ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2002-03-05 21:41 Message: Logged In: NO When applying this patch I get an error with Hunk 1 and Defaults.py is not updated. This happens with the a clean download of the latest cvs installation (5 Mar 2002). Any ideas what the problem is? ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-17 16:53 Message: Logged In: YES user_id=75166 indexing-2.1cvs-20011217.patch is a revised version of the patch that is compatible with the code published in mailman CVS on sourceforge as 11:50 GMT 17 Dec 2001 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-12-13 16:48 Message: Logged In: YES user_id=75166 indexing-2.1a3-0.1.patch is a revised version of the patch that is compatible with the code published in mailman-2.1a3.tgz on sourceforge. ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-28 11:07 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.8 ---------------------------------------------------------------------- Comment By: Richard Barrett (ppsys) Date: 2001-11-27 12:03 Message: Logged In: YES user_id=75166 This patch should also apply without problems to MM 2.0.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=444879&group_i…

1 0

[ mailman-Feature Requests-1234579 ] hiding e-mail addresses in public archive
by SourceForge.net 19 Apr '06

19 Apr '06

Feature Requests item #1234579, was opened at 2005-07-07 23:13 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1234579&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Abracode (abracode) Assigned to: Nobody/Anonymous (nobody) Summary: hiding e-mail addresses in public archive Initial Comment: I would love to see an option to hide e-mail addresses of senders in the public archive - only in the archive and only e-mails, not names. Simple e-mail obfuscation (like joe at schmo.com) is not good enough nowadays with more and more advanced/malicious e-mail harvesters. Thanks, Tom ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-19 14:38 Message: Logged In: YES user_id=12800 Please add this as a comment to the Mailman 2.2 wiki page: http://wiki.list.org/display/DEV/Mailman+2.2 The idea is to implement all archive access as a dynamic process (cgi) and then we'll be able to modify the obfuscation algorithm on the fly as older methods become obsolete. ---------------------------------------------------------------------- Comment By: eht16 (eht16) Date: 2006-04-19 14:29 Message: Logged In: YES user_id=1117045 I also need this feature. Are there any news about it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1234579&group_…

1 0

[ mailman-Feature Requests-1234579 ] hiding e-mail addresses in public archive
by SourceForge.net 19 Apr '06

19 Apr '06

Feature Requests item #1234579, was opened at 2005-07-08 05:13 Message generated for change (Comment added) made by eht16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1234579&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Abracode (abracode) Assigned to: Nobody/Anonymous (nobody) Summary: hiding e-mail addresses in public archive Initial Comment: I would love to see an option to hide e-mail addresses of senders in the public archive - only in the archive and only e-mails, not names. Simple e-mail obfuscation (like joe at schmo.com) is not good enough nowadays with more and more advanced/malicious e-mail harvesters. Thanks, Tom ---------------------------------------------------------------------- Comment By: eht16 (eht16) Date: 2006-04-19 20:29 Message: Logged In: YES user_id=1117045 I also need this feature. Are there any news about it? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1234579&group_…

1 0

[ mailman-Feature Requests-1472242 ] search user subscription lists
by SourceForge.net 18 Apr '06

18 Apr '06

Feature Requests item #1472242, was opened at 2006-04-18 04:58 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1472242&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Pending Resolution: None Priority: 5 Submitted By: alcarobe (alcarobe) Assigned to: Nobody/Anonymous (nobody) Summary: search user subscription lists Initial Comment: mailman now allows to find all or a dedicated mailing list another useful search facility should be added to allow people to find all the lists where they are subscribed to ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-04-18 12:16 Message: Logged In: YES user_id=1123998 If you are asking for something other that the "List my other subscriptions" search that currently exists on the user options page, please clarify what it is you want. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1472242&group_…

1 0

[ mailman-Bugs-1471318 ] Missing Date header in "requires approval" attachment
by SourceForge.net 18 Apr '06

18 Apr '06

Bugs item #1471318, was opened at 2006-04-16 17:22 Message generated for change (Comment added) made by hporten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Harri Porten (hporten) Assigned to: Nobody/Anonymous (nobody) Summary: Missing Date header in "requires approval" attachment Initial Comment: The message attachment part of the "xxx post from xxx(a)xxx.xx requires approval" mails sent to the list admin are lacking a Date header. The part currently starts with Content-Type: message/rfc822 MIME-Version: 1.0 while RFC822 mandates a Dates header to exist. This is with version 2.1.5 compiled with sources on a Debian 3.1 system. I've seen that the lack of the header has been fixed for other types of mails but not the attachment of this admin mail. Harri. ---------------------------------------------------------------------- >Comment By: Harri Porten (hporten) Date: 2006-04-18 19:37 Message: Logged In: YES user_id=873548 It's called Archiveopteryx. A system of servers that stores mails in a SQL database and makes them available through IMAP etc. See http://www.archiveopteryx.org/ ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-18 19:05 Message: Logged In: YES user_id=12800 Can you tell us what the "mail storage software" actually is? It would be nice to know for the future. It doesn't seem especially "liberal in what you accept and strict in what you produce". ---------------------------------------------------------------------- Comment By: Harri Porten (hporten) Date: 2006-04-18 18:21 Message: Logged In: YES user_id=873548 FYI, the error message I'm getting from our mail storage software (I perhaps shouldn't have called it MTA previously): "The appended message was received, but could not be stored in the mail database on imap.example.com. The error detected was: In message/rfc822 part: 0 Date fields seen. At least 1 must be present." The server wants to store incoming mails in a database for later retrieval. As the part is marked as rfc822 it applies the corresponding rules. Whether a MUA would later add a Date header later is not relevant in this case. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-18 14:41 Message: Logged In: YES user_id=12800 Which you've done, so that's good enough for me! Thanks. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-18 07:27 Message: Logged In: YES user_id=1123998 I agree that it is mostly harmless either way, but I think it is correct to include it. The attachment is a message/rfc822 part and while it never passed through a mail system as an individual message, it was actually sent as part of an enclosing message at the time in the header. Presumably, the recipient list admin will open the attached message in an MUA and reply to it. When opened, it will look like a message that was sent at the time in the Date header we insert which is actually when it was crafted and sent, and a functional MUA will insert the current time of the reply in the Date header of the reply, just as it would when replying to any other message. I'm not sure what is complaining or what the exact complaint is in Harri's case, so I don't know what the resultant Date in his reply will be. I do agree, that if the list admin is (manually) extracting the confirmation message from the notice and posting it directly to an MTA, it would probably be better if we hadn't put the Date in it, but it seems to be a situation where we can't be 100% right whatever we do, and both RFC822 and RFC2822 say a compliant message is required to have a Date, so I lean towards putting it in. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-18 06:06 Message: Logged In: YES user_id=12800 I'm not sure I agree that the confirm attachment should have a Date header. It's mostly harmless, so I won't argue too much, but the Date header is supposed to reflect the time that the originator injects the message into the system. The creation of the attachment by Mailman is not the time at which the confirm message is injected into the system. That would be when the recipient of the confirmation uses that attachment to generate their confirmation. The header should reflect the Date of that use, which can be significantly removed in time from when the attachment was generated. I think any MUA that doesn't include it's own Date header in a reply to the attachment, and sends that to an MTA that requires a Date header is broken. But as I say, I think it's probably harmless to add it anyway, so if you want to leave it, I won't complain. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-18 00:02 Message: Logged In: YES user_id=1123998 Patch committed to subversion trunk. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 23:37 Message: Logged In: YES user_id=1123998 You are correct. The attached, Mailman generated "confirm" message lacks a Date: header. This is wrong. The attached patch against the 2.1.8 base should fix the problem. It will be incorporated in the next release. ---------------------------------------------------------------------- Comment By: Harri Porten (hporten) Date: 2006-04-17 21:06 Message: Logged In: YES user_id=873548 Sorry. I just realized that I quoted the wrong set of headers in my report. My MTA is apparantly complaining about the lack of the Date header in the *last* part as generated by Mailman: --===============0382486014== Content-Type: message/rfc822 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: confirm eb636a7c7c9eff5aa0db306a3a2666d5baf486b0 Sender: test-request(a)example.com From: test-request(a)example.com If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. --===============0382486014==-- Or does your answer apply to this part as well? I see that RFC 1521 does indeed relax the 822 restrictions. Not sure about the Date requirement, though. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-16 17:50 Message: Logged In: YES user_id=1123998 RFC822 and RFC2822 only address the top level message headers. The standard for the headers of sub-parts in multipart messages is RFC1521. A Date header is not required in the headers of a sub-part. If your issue is that the attached message/rfc822 part itself contains no date header, this is an exact copy of the message received by Mailman. It was up to whatever sent the original message to include a Date: header. If mailman receives a non-compliant message and holds it for approval, it is not up to Mailman to try to correct defects in the received message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_…

1 0

[ mailman-Bugs-1471318 ] Missing Date header in "requires approval" attachment
by SourceForge.net 18 Apr '06

18 Apr '06

Bugs item #1471318, was opened at 2006-04-16 11:22 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Harri Porten (hporten) Assigned to: Nobody/Anonymous (nobody) Summary: Missing Date header in "requires approval" attachment Initial Comment: The message attachment part of the "xxx post from xxx(a)xxx.xx requires approval" mails sent to the list admin are lacking a Date header. The part currently starts with Content-Type: message/rfc822 MIME-Version: 1.0 while RFC822 mandates a Dates header to exist. This is with version 2.1.5 compiled with sources on a Debian 3.1 system. I've seen that the lack of the header has been fixed for other types of mails but not the attachment of this admin mail. Harri. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-18 13:05 Message: Logged In: YES user_id=12800 Can you tell us what the "mail storage software" actually is? It would be nice to know for the future. It doesn't seem especially "liberal in what you accept and strict in what you produce". ---------------------------------------------------------------------- Comment By: Harri Porten (hporten) Date: 2006-04-18 12:21 Message: Logged In: YES user_id=873548 FYI, the error message I'm getting from our mail storage software (I perhaps shouldn't have called it MTA previously): "The appended message was received, but could not be stored in the mail database on imap.example.com. The error detected was: In message/rfc822 part: 0 Date fields seen. At least 1 must be present." The server wants to store incoming mails in a database for later retrieval. As the part is marked as rfc822 it applies the corresponding rules. Whether a MUA would later add a Date header later is not relevant in this case. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-18 08:41 Message: Logged In: YES user_id=12800 Which you've done, so that's good enough for me! Thanks. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-18 01:27 Message: Logged In: YES user_id=1123998 I agree that it is mostly harmless either way, but I think it is correct to include it. The attachment is a message/rfc822 part and while it never passed through a mail system as an individual message, it was actually sent as part of an enclosing message at the time in the header. Presumably, the recipient list admin will open the attached message in an MUA and reply to it. When opened, it will look like a message that was sent at the time in the Date header we insert which is actually when it was crafted and sent, and a functional MUA will insert the current time of the reply in the Date header of the reply, just as it would when replying to any other message. I'm not sure what is complaining or what the exact complaint is in Harri's case, so I don't know what the resultant Date in his reply will be. I do agree, that if the list admin is (manually) extracting the confirmation message from the notice and posting it directly to an MTA, it would probably be better if we hadn't put the Date in it, but it seems to be a situation where we can't be 100% right whatever we do, and both RFC822 and RFC2822 say a compliant message is required to have a Date, so I lean towards putting it in. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-18 00:06 Message: Logged In: YES user_id=12800 I'm not sure I agree that the confirm attachment should have a Date header. It's mostly harmless, so I won't argue too much, but the Date header is supposed to reflect the time that the originator injects the message into the system. The creation of the attachment by Mailman is not the time at which the confirm message is injected into the system. That would be when the recipient of the confirmation uses that attachment to generate their confirmation. The header should reflect the Date of that use, which can be significantly removed in time from when the attachment was generated. I think any MUA that doesn't include it's own Date header in a reply to the attachment, and sends that to an MTA that requires a Date header is broken. But as I say, I think it's probably harmless to add it anyway, so if you want to leave it, I won't complain. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 18:02 Message: Logged In: YES user_id=1123998 Patch committed to subversion trunk. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 17:37 Message: Logged In: YES user_id=1123998 You are correct. The attached, Mailman generated "confirm" message lacks a Date: header. This is wrong. The attached patch against the 2.1.8 base should fix the problem. It will be incorporated in the next release. ---------------------------------------------------------------------- Comment By: Harri Porten (hporten) Date: 2006-04-17 15:06 Message: Logged In: YES user_id=873548 Sorry. I just realized that I quoted the wrong set of headers in my report. My MTA is apparantly complaining about the lack of the Date header in the *last* part as generated by Mailman: --===============0382486014== Content-Type: message/rfc822 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: confirm eb636a7c7c9eff5aa0db306a3a2666d5baf486b0 Sender: test-request(a)example.com From: test-request(a)example.com If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. --===============0382486014==-- Or does your answer apply to this part as well? I see that RFC 1521 does indeed relax the 822 restrictions. Not sure about the Date requirement, though. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-16 11:50 Message: Logged In: YES user_id=1123998 RFC822 and RFC2822 only address the top level message headers. The standard for the headers of sub-parts in multipart messages is RFC1521. A Date header is not required in the headers of a sub-part. If your issue is that the attached message/rfc822 part itself contains no date header, this is an exact copy of the message received by Mailman. It was up to whatever sent the original message to include a Date: header. If mailman receives a non-compliant message and holds it for approval, it is not up to Mailman to try to correct defects in the received message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_…

1 0

[ mailman-Bugs-1471318 ] Missing Date header in "requires approval" attachment
by SourceForge.net 18 Apr '06

18 Apr '06

Bugs item #1471318, was opened at 2006-04-16 17:22 Message generated for change (Comment added) made by hporten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Harri Porten (hporten) Assigned to: Nobody/Anonymous (nobody) Summary: Missing Date header in "requires approval" attachment Initial Comment: The message attachment part of the "xxx post from xxx(a)xxx.xx requires approval" mails sent to the list admin are lacking a Date header. The part currently starts with Content-Type: message/rfc822 MIME-Version: 1.0 while RFC822 mandates a Dates header to exist. This is with version 2.1.5 compiled with sources on a Debian 3.1 system. I've seen that the lack of the header has been fixed for other types of mails but not the attachment of this admin mail. Harri. ---------------------------------------------------------------------- >Comment By: Harri Porten (hporten) Date: 2006-04-18 18:21 Message: Logged In: YES user_id=873548 FYI, the error message I'm getting from our mail storage software (I perhaps shouldn't have called it MTA previously): "The appended message was received, but could not be stored in the mail database on imap.example.com. The error detected was: In message/rfc822 part: 0 Date fields seen. At least 1 must be present." The server wants to store incoming mails in a database for later retrieval. As the part is marked as rfc822 it applies the corresponding rules. Whether a MUA would later add a Date header later is not relevant in this case. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-18 14:41 Message: Logged In: YES user_id=12800 Which you've done, so that's good enough for me! Thanks. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-18 07:27 Message: Logged In: YES user_id=1123998 I agree that it is mostly harmless either way, but I think it is correct to include it. The attachment is a message/rfc822 part and while it never passed through a mail system as an individual message, it was actually sent as part of an enclosing message at the time in the header. Presumably, the recipient list admin will open the attached message in an MUA and reply to it. When opened, it will look like a message that was sent at the time in the Date header we insert which is actually when it was crafted and sent, and a functional MUA will insert the current time of the reply in the Date header of the reply, just as it would when replying to any other message. I'm not sure what is complaining or what the exact complaint is in Harri's case, so I don't know what the resultant Date in his reply will be. I do agree, that if the list admin is (manually) extracting the confirmation message from the notice and posting it directly to an MTA, it would probably be better if we hadn't put the Date in it, but it seems to be a situation where we can't be 100% right whatever we do, and both RFC822 and RFC2822 say a compliant message is required to have a Date, so I lean towards putting it in. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-18 06:06 Message: Logged In: YES user_id=12800 I'm not sure I agree that the confirm attachment should have a Date header. It's mostly harmless, so I won't argue too much, but the Date header is supposed to reflect the time that the originator injects the message into the system. The creation of the attachment by Mailman is not the time at which the confirm message is injected into the system. That would be when the recipient of the confirmation uses that attachment to generate their confirmation. The header should reflect the Date of that use, which can be significantly removed in time from when the attachment was generated. I think any MUA that doesn't include it's own Date header in a reply to the attachment, and sends that to an MTA that requires a Date header is broken. But as I say, I think it's probably harmless to add it anyway, so if you want to leave it, I won't complain. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-18 00:02 Message: Logged In: YES user_id=1123998 Patch committed to subversion trunk. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 23:37 Message: Logged In: YES user_id=1123998 You are correct. The attached, Mailman generated "confirm" message lacks a Date: header. This is wrong. The attached patch against the 2.1.8 base should fix the problem. It will be incorporated in the next release. ---------------------------------------------------------------------- Comment By: Harri Porten (hporten) Date: 2006-04-17 21:06 Message: Logged In: YES user_id=873548 Sorry. I just realized that I quoted the wrong set of headers in my report. My MTA is apparantly complaining about the lack of the Date header in the *last* part as generated by Mailman: --===============0382486014== Content-Type: message/rfc822 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: confirm eb636a7c7c9eff5aa0db306a3a2666d5baf486b0 Sender: test-request(a)example.com From: test-request(a)example.com If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. --===============0382486014==-- Or does your answer apply to this part as well? I see that RFC 1521 does indeed relax the 822 restrictions. Not sure about the Date requirement, though. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-16 17:50 Message: Logged In: YES user_id=1123998 RFC822 and RFC2822 only address the top level message headers. The standard for the headers of sub-parts in multipart messages is RFC1521. A Date header is not required in the headers of a sub-part. If your issue is that the attached message/rfc822 part itself contains no date header, this is an exact copy of the message received by Mailman. It was up to whatever sent the original message to include a Date: header. If mailman receives a non-compliant message and holds it for approval, it is not up to Mailman to try to correct defects in the received message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_…

1 0

[ mailman-Bugs-1471318 ] Missing Date header in "requires approval" attachment
by SourceForge.net 18 Apr '06

18 Apr '06

Bugs item #1471318, was opened at 2006-04-16 11:22 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Harri Porten (hporten) Assigned to: Nobody/Anonymous (nobody) Summary: Missing Date header in "requires approval" attachment Initial Comment: The message attachment part of the "xxx post from xxx(a)xxx.xx requires approval" mails sent to the list admin are lacking a Date header. The part currently starts with Content-Type: message/rfc822 MIME-Version: 1.0 while RFC822 mandates a Dates header to exist. This is with version 2.1.5 compiled with sources on a Debian 3.1 system. I've seen that the lack of the header has been fixed for other types of mails but not the attachment of this admin mail. Harri. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-18 08:41 Message: Logged In: YES user_id=12800 Which you've done, so that's good enough for me! Thanks. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-18 01:27 Message: Logged In: YES user_id=1123998 I agree that it is mostly harmless either way, but I think it is correct to include it. The attachment is a message/rfc822 part and while it never passed through a mail system as an individual message, it was actually sent as part of an enclosing message at the time in the header. Presumably, the recipient list admin will open the attached message in an MUA and reply to it. When opened, it will look like a message that was sent at the time in the Date header we insert which is actually when it was crafted and sent, and a functional MUA will insert the current time of the reply in the Date header of the reply, just as it would when replying to any other message. I'm not sure what is complaining or what the exact complaint is in Harri's case, so I don't know what the resultant Date in his reply will be. I do agree, that if the list admin is (manually) extracting the confirmation message from the notice and posting it directly to an MTA, it would probably be better if we hadn't put the Date in it, but it seems to be a situation where we can't be 100% right whatever we do, and both RFC822 and RFC2822 say a compliant message is required to have a Date, so I lean towards putting it in. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-18 00:06 Message: Logged In: YES user_id=12800 I'm not sure I agree that the confirm attachment should have a Date header. It's mostly harmless, so I won't argue too much, but the Date header is supposed to reflect the time that the originator injects the message into the system. The creation of the attachment by Mailman is not the time at which the confirm message is injected into the system. That would be when the recipient of the confirmation uses that attachment to generate their confirmation. The header should reflect the Date of that use, which can be significantly removed in time from when the attachment was generated. I think any MUA that doesn't include it's own Date header in a reply to the attachment, and sends that to an MTA that requires a Date header is broken. But as I say, I think it's probably harmless to add it anyway, so if you want to leave it, I won't complain. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 18:02 Message: Logged In: YES user_id=1123998 Patch committed to subversion trunk. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 17:37 Message: Logged In: YES user_id=1123998 You are correct. The attached, Mailman generated "confirm" message lacks a Date: header. This is wrong. The attached patch against the 2.1.8 base should fix the problem. It will be incorporated in the next release. ---------------------------------------------------------------------- Comment By: Harri Porten (hporten) Date: 2006-04-17 15:06 Message: Logged In: YES user_id=873548 Sorry. I just realized that I quoted the wrong set of headers in my report. My MTA is apparantly complaining about the lack of the Date header in the *last* part as generated by Mailman: --===============0382486014== Content-Type: message/rfc822 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: confirm eb636a7c7c9eff5aa0db306a3a2666d5baf486b0 Sender: test-request(a)example.com From: test-request(a)example.com If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. --===============0382486014==-- Or does your answer apply to this part as well? I see that RFC 1521 does indeed relax the 822 restrictions. Not sure about the Date requirement, though. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-16 11:50 Message: Logged In: YES user_id=1123998 RFC822 and RFC2822 only address the top level message headers. The standard for the headers of sub-parts in multipart messages is RFC1521. A Date header is not required in the headers of a sub-part. If your issue is that the attached message/rfc822 part itself contains no date header, this is an exact copy of the message received by Mailman. It was up to whatever sent the original message to include a Date: header. If mailman receives a non-compliant message and holds it for approval, it is not up to Mailman to try to correct defects in the received message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_…

1 0

[ mailman-Feature Requests-1472242 ] search user subscription lists
by SourceForge.net 18 Apr '06

18 Apr '06

Feature Requests item #1472242, was opened at 2006-04-18 11:58 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1472242&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: alcarobe (alcarobe) Assigned to: Nobody/Anonymous (nobody) Summary: search user subscription lists Initial Comment: mailman now allows to find all or a dedicated mailing list another useful search facility should be added to allow people to find all the lists where they are subscribed to ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1472242&group_…

1 0

[ mailman-Bugs-1471318 ] Missing Date header in "requires approval" attachment
by SourceForge.net 18 Apr '06

18 Apr '06

Bugs item #1471318, was opened at 2006-04-16 08:22 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Harri Porten (hporten) Assigned to: Nobody/Anonymous (nobody) Summary: Missing Date header in "requires approval" attachment Initial Comment: The message attachment part of the "xxx post from xxx(a)xxx.xx requires approval" mails sent to the list admin are lacking a Date header. The part currently starts with Content-Type: message/rfc822 MIME-Version: 1.0 while RFC822 mandates a Dates header to exist. This is with version 2.1.5 compiled with sources on a Debian 3.1 system. I've seen that the lack of the header has been fixed for other types of mails but not the attachment of this admin mail. Harri. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 22:27 Message: Logged In: YES user_id=1123998 I agree that it is mostly harmless either way, but I think it is correct to include it. The attachment is a message/rfc822 part and while it never passed through a mail system as an individual message, it was actually sent as part of an enclosing message at the time in the header. Presumably, the recipient list admin will open the attached message in an MUA and reply to it. When opened, it will look like a message that was sent at the time in the Date header we insert which is actually when it was crafted and sent, and a functional MUA will insert the current time of the reply in the Date header of the reply, just as it would when replying to any other message. I'm not sure what is complaining or what the exact complaint is in Harri's case, so I don't know what the resultant Date in his reply will be. I do agree, that if the list admin is (manually) extracting the confirmation message from the notice and posting it directly to an MTA, it would probably be better if we hadn't put the Date in it, but it seems to be a situation where we can't be 100% right whatever we do, and both RFC822 and RFC2822 say a compliant message is required to have a Date, so I lean towards putting it in. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-17 21:06 Message: Logged In: YES user_id=12800 I'm not sure I agree that the confirm attachment should have a Date header. It's mostly harmless, so I won't argue too much, but the Date header is supposed to reflect the time that the originator injects the message into the system. The creation of the attachment by Mailman is not the time at which the confirm message is injected into the system. That would be when the recipient of the confirmation uses that attachment to generate their confirmation. The header should reflect the Date of that use, which can be significantly removed in time from when the attachment was generated. I think any MUA that doesn't include it's own Date header in a reply to the attachment, and sends that to an MTA that requires a Date header is broken. But as I say, I think it's probably harmless to add it anyway, so if you want to leave it, I won't complain. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 15:02 Message: Logged In: YES user_id=1123998 Patch committed to subversion trunk. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 14:37 Message: Logged In: YES user_id=1123998 You are correct. The attached, Mailman generated "confirm" message lacks a Date: header. This is wrong. The attached patch against the 2.1.8 base should fix the problem. It will be incorporated in the next release. ---------------------------------------------------------------------- Comment By: Harri Porten (hporten) Date: 2006-04-17 12:06 Message: Logged In: YES user_id=873548 Sorry. I just realized that I quoted the wrong set of headers in my report. My MTA is apparantly complaining about the lack of the Date header in the *last* part as generated by Mailman: --===============0382486014== Content-Type: message/rfc822 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: confirm eb636a7c7c9eff5aa0db306a3a2666d5baf486b0 Sender: test-request(a)example.com From: test-request(a)example.com If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. --===============0382486014==-- Or does your answer apply to this part as well? I see that RFC 1521 does indeed relax the 822 restrictions. Not sure about the Date requirement, though. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-16 08:50 Message: Logged In: YES user_id=1123998 RFC822 and RFC2822 only address the top level message headers. The standard for the headers of sub-parts in multipart messages is RFC1521. A Date header is not required in the headers of a sub-part. If your issue is that the attached message/rfc822 part itself contains no date header, this is an exact copy of the message received by Mailman. It was up to whatever sent the original message to include a Date: header. If mailman receives a non-compliant message and holds it for approval, it is not up to Mailman to try to correct defects in the received message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_…

1 0

[ mailman-Bugs-1471318 ] Missing Date header in "requires approval" attachment
by SourceForge.net 17 Apr '06

17 Apr '06

Bugs item #1471318, was opened at 2006-04-16 11:22 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Closed Resolution: Fixed Priority: 5 Submitted By: Harri Porten (hporten) Assigned to: Nobody/Anonymous (nobody) Summary: Missing Date header in "requires approval" attachment Initial Comment: The message attachment part of the "xxx post from xxx(a)xxx.xx requires approval" mails sent to the list admin are lacking a Date header. The part currently starts with Content-Type: message/rfc822 MIME-Version: 1.0 while RFC822 mandates a Dates header to exist. This is with version 2.1.5 compiled with sources on a Debian 3.1 system. I've seen that the lack of the header has been fixed for other types of mails but not the attachment of this admin mail. Harri. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-18 00:06 Message: Logged In: YES user_id=12800 I'm not sure I agree that the confirm attachment should have a Date header. It's mostly harmless, so I won't argue too much, but the Date header is supposed to reflect the time that the originator injects the message into the system. The creation of the attachment by Mailman is not the time at which the confirm message is injected into the system. That would be when the recipient of the confirmation uses that attachment to generate their confirmation. The header should reflect the Date of that use, which can be significantly removed in time from when the attachment was generated. I think any MUA that doesn't include it's own Date header in a reply to the attachment, and sends that to an MTA that requires a Date header is broken. But as I say, I think it's probably harmless to add it anyway, so if you want to leave it, I won't complain. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 18:02 Message: Logged In: YES user_id=1123998 Patch committed to subversion trunk. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 17:37 Message: Logged In: YES user_id=1123998 You are correct. The attached, Mailman generated "confirm" message lacks a Date: header. This is wrong. The attached patch against the 2.1.8 base should fix the problem. It will be incorporated in the next release. ---------------------------------------------------------------------- Comment By: Harri Porten (hporten) Date: 2006-04-17 15:06 Message: Logged In: YES user_id=873548 Sorry. I just realized that I quoted the wrong set of headers in my report. My MTA is apparantly complaining about the lack of the Date header in the *last* part as generated by Mailman: --===============0382486014== Content-Type: message/rfc822 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: confirm eb636a7c7c9eff5aa0db306a3a2666d5baf486b0 Sender: test-request(a)example.com From: test-request(a)example.com If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. --===============0382486014==-- Or does your answer apply to this part as well? I see that RFC 1521 does indeed relax the 822 restrictions. Not sure about the Date requirement, though. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-16 11:50 Message: Logged In: YES user_id=1123998 RFC822 and RFC2822 only address the top level message headers. The standard for the headers of sub-parts in multipart messages is RFC1521. A Date header is not required in the headers of a sub-part. If your issue is that the attached message/rfc822 part itself contains no date header, this is an exact copy of the message received by Mailman. It was up to whatever sent the original message to include a Date: header. If mailman receives a non-compliant message and holds it for approval, it is not up to Mailman to try to correct defects in the received message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_…

1 0

[ mailman-Bugs-1471318 ] Missing Date header in "requires approval" attachment
by SourceForge.net 17 Apr '06

17 Apr '06

Bugs item #1471318, was opened at 2006-04-16 08:22 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Harri Porten (hporten) Assigned to: Nobody/Anonymous (nobody) Summary: Missing Date header in "requires approval" attachment Initial Comment: The message attachment part of the "xxx post from xxx(a)xxx.xx requires approval" mails sent to the list admin are lacking a Date header. The part currently starts with Content-Type: message/rfc822 MIME-Version: 1.0 while RFC822 mandates a Dates header to exist. This is with version 2.1.5 compiled with sources on a Debian 3.1 system. I've seen that the lack of the header has been fixed for other types of mails but not the attachment of this admin mail. Harri. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 15:02 Message: Logged In: YES user_id=1123998 Patch committed to subversion trunk. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 14:37 Message: Logged In: YES user_id=1123998 You are correct. The attached, Mailman generated "confirm" message lacks a Date: header. This is wrong. The attached patch against the 2.1.8 base should fix the problem. It will be incorporated in the next release. ---------------------------------------------------------------------- Comment By: Harri Porten (hporten) Date: 2006-04-17 12:06 Message: Logged In: YES user_id=873548 Sorry. I just realized that I quoted the wrong set of headers in my report. My MTA is apparantly complaining about the lack of the Date header in the *last* part as generated by Mailman: --===============0382486014== Content-Type: message/rfc822 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: confirm eb636a7c7c9eff5aa0db306a3a2666d5baf486b0 Sender: test-request(a)example.com From: test-request(a)example.com If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. --===============0382486014==-- Or does your answer apply to this part as well? I see that RFC 1521 does indeed relax the 822 restrictions. Not sure about the Date requirement, though. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-16 08:50 Message: Logged In: YES user_id=1123998 RFC822 and RFC2822 only address the top level message headers. The standard for the headers of sub-parts in multipart messages is RFC1521. A Date header is not required in the headers of a sub-part. If your issue is that the attached message/rfc822 part itself contains no date header, this is an exact copy of the message received by Mailman. It was up to whatever sent the original message to include a Date: header. If mailman receives a non-compliant message and holds it for approval, it is not up to Mailman to try to correct defects in the received message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_…

1 0

[ mailman-Bugs-1471318 ] Missing Date header in "requires approval" attachment
by SourceForge.net 17 Apr '06

17 Apr '06

Bugs item #1471318, was opened at 2006-04-16 08:22 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Harri Porten (hporten) Assigned to: Nobody/Anonymous (nobody) Summary: Missing Date header in "requires approval" attachment Initial Comment: The message attachment part of the "xxx post from xxx(a)xxx.xx requires approval" mails sent to the list admin are lacking a Date header. The part currently starts with Content-Type: message/rfc822 MIME-Version: 1.0 while RFC822 mandates a Dates header to exist. This is with version 2.1.5 compiled with sources on a Debian 3.1 system. I've seen that the lack of the header has been fixed for other types of mails but not the attachment of this admin mail. Harri. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 14:37 Message: Logged In: YES user_id=1123998 You are correct. The attached, Mailman generated "confirm" message lacks a Date: header. This is wrong. The attached patch against the 2.1.8 base should fix the problem. It will be incorporated in the next release. ---------------------------------------------------------------------- Comment By: Harri Porten (hporten) Date: 2006-04-17 12:06 Message: Logged In: YES user_id=873548 Sorry. I just realized that I quoted the wrong set of headers in my report. My MTA is apparantly complaining about the lack of the Date header in the *last* part as generated by Mailman: --===============0382486014== Content-Type: message/rfc822 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: confirm eb636a7c7c9eff5aa0db306a3a2666d5baf486b0 Sender: test-request(a)example.com From: test-request(a)example.com If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. --===============0382486014==-- Or does your answer apply to this part as well? I see that RFC 1521 does indeed relax the 822 restrictions. Not sure about the Date requirement, though. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-16 08:50 Message: Logged In: YES user_id=1123998 RFC822 and RFC2822 only address the top level message headers. The standard for the headers of sub-parts in multipart messages is RFC1521. A Date header is not required in the headers of a sub-part. If your issue is that the attached message/rfc822 part itself contains no date header, this is an exact copy of the message received by Mailman. It was up to whatever sent the original message to include a Date: header. If mailman receives a non-compliant message and holds it for approval, it is not up to Mailman to try to correct defects in the received message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_…

1 0

[ mailman-Bugs-1471318 ] Missing Date header in "requires approval" attachment
by SourceForge.net 17 Apr '06

17 Apr '06

Bugs item #1471318, was opened at 2006-04-16 17:22 Message generated for change (Comment added) made by hporten You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) >Status: Open >Resolution: None Priority: 5 Submitted By: Harri Porten (hporten) Assigned to: Nobody/Anonymous (nobody) Summary: Missing Date header in "requires approval" attachment Initial Comment: The message attachment part of the "xxx post from xxx(a)xxx.xx requires approval" mails sent to the list admin are lacking a Date header. The part currently starts with Content-Type: message/rfc822 MIME-Version: 1.0 while RFC822 mandates a Dates header to exist. This is with version 2.1.5 compiled with sources on a Debian 3.1 system. I've seen that the lack of the header has been fixed for other types of mails but not the attachment of this admin mail. Harri. ---------------------------------------------------------------------- >Comment By: Harri Porten (hporten) Date: 2006-04-17 21:06 Message: Logged In: YES user_id=873548 Sorry. I just realized that I quoted the wrong set of headers in my report. My MTA is apparantly complaining about the lack of the Date header in the *last* part as generated by Mailman: --===============0382486014== Content-Type: message/rfc822 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: confirm eb636a7c7c9eff5aa0db306a3a2666d5baf486b0 Sender: test-request(a)example.com From: test-request(a)example.com If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. --===============0382486014==-- Or does your answer apply to this part as well? I see that RFC 1521 does indeed relax the 822 restrictions. Not sure about the Date requirement, though. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-16 17:50 Message: Logged In: YES user_id=1123998 RFC822 and RFC2822 only address the top level message headers. The standard for the headers of sub-parts in multipart messages is RFC1521. A Date header is not required in the headers of a sub-part. If your issue is that the attached message/rfc822 part itself contains no date header, this is an exact copy of the message received by Mailman. It was up to whatever sent the original message to include a Date: header. If mailman receives a non-compliant message and holds it for approval, it is not up to Mailman to try to correct defects in the received message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_…

1 0

[ mailman-Patches-1086319 ] bin/show_qfiles is terminated by exception
by SourceForge.net 17 Apr '06

17 Apr '06

Patches item #1086319, was opened at 2004-12-16 01:10 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1086319&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: command line scripts Group: Mailman 2.1 >Status: Closed Resolution: Fixed Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Nobody/Anonymous (nobody) Summary: bin/show_qfiles is terminated by exception Initial Comment: Shunted queue files may cause exceptions while bin/show_qfiles is running. By this patch, show_qfiles will show tracebacks and continue processing files. ---------------------------------------------------------------------- Comment By: Hatuka*nezumi (hatukanezumi) Date: 2006-04-17 03:19 Message: Logged In: YES user_id=529503 I guess Bug #1444447 is diferent problem. But on 2.1.8 (without patch), qfiles that caused exception on 2.1.6- don't cause exception. So please mark this item 'closed'. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-16 08:02 Message: Logged In: YES user_id=1123998 I think the underlying problem is Bug # 1444447 which is fixed in a different way in Mailman 2.1.8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1086319&group_…

1 0

[ mailman-Patches-1086319 ] bin/show_qfiles is terminated by exception
by SourceForge.net 17 Apr '06

17 Apr '06

Patches item #1086319, was opened at 2004-12-16 18:10 Message generated for change (Comment added) made by hatukanezumi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1086319&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: command line scripts Group: Mailman 2.1 >Status: Open Resolution: Fixed Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Nobody/Anonymous (nobody) Summary: bin/show_qfiles is terminated by exception Initial Comment: Shunted queue files may cause exceptions while bin/show_qfiles is running. By this patch, show_qfiles will show tracebacks and continue processing files. ---------------------------------------------------------------------- >Comment By: Hatuka*nezumi (hatukanezumi) Date: 2006-04-17 19:19 Message: Logged In: YES user_id=529503 I guess Bug #1444447 is diferent problem. But on 2.1.8 (without patch), qfiles that caused exception on 2.1.6- don't cause exception. So please mark this item 'closed'. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-17 00:02 Message: Logged In: YES user_id=1123998 I think the underlying problem is Bug # 1444447 which is fixed in a different way in Mailman 2.1.8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1086319&group_…

1 0

[ mailman-Bugs-1471487 ] ASCII decoding error in membership management
by SourceForge.net 16 Apr '06

16 Apr '06

Bugs item #1471487, was opened at 2006-04-16 16:32 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471487&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Andreas Thienemann (ixsnet) Assigned to: Nobody/Anonymous (nobody) Summary: ASCII decoding error in membership management Initial Comment: When opening the list membership management view in the admin interface, a notice about hitting a bug in 2.1.7 appears. The error log has some more information: admin(31507): [----- Mailman Version: 2.1.7 -----] admin(31507): [----- Traceback ------] admin(31507): Traceback (most recent call last): admin(31507): File "/opt/mailman-2.1.7/scripts/driver", line 101, in run_main admin(31507): main() admin(31507): File "/opt/mailman-2.1.7/Mailman/Cgi/admin.py", line 197, in main admin(31507): show_results(mlist, doc, category, subcat, cgidata) admin(31507): File "/opt/mailman-2.1.7/Mailman/Cgi/admin.py", line 497, in show_results admin(31507): form.AddItem(membership_options(mlist, subcat, cgidata, doc, form)) admin(31507): File "/opt/mailman-2.1.7/Mailman/Cgi/admin.py", line 869, in membership_options admin(31507): all = [_m.encode() for _m in mlist.getMembers()] admin(31507): UnicodeError: ASCII decoding error: ordinal not in range(128) admin(31507): [----- Python Information -----] admin(31507): sys.version = 2.2.3 (#1, Nov 11 2003, 17:44:56) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] admin(31507): sys.executable = /usr/bin/python2 admin(31507): sys.prefix = /usr admin(31507): sys.exec_prefix = /usr admin(31507): sys.path = /usr admin(31507): sys.platform = linux2 ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-04-16 18:51 Message: Logged In: YES user_id=1123998 Did you just upgrade from Mailman 2.1.2 or older? It appears that this list has one or more members with (invalid?) non-ascii characters in their email address. I think any version from 2.1.3 on would throw this exception, and no recent version would allow the address to be added. You might try something like bin/list_members listname | egrep '[^[:alnum:]@.-]' to find the offending address. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471487&group_…

1 0

[ mailman-Bugs-1471487 ] ASCII decoding error in membership management
by SourceForge.net 16 Apr '06

16 Apr '06

Bugs item #1471487, was opened at 2006-04-16 23:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471487&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Andreas Thienemann (ixsnet) Assigned to: Nobody/Anonymous (nobody) Summary: ASCII decoding error in membership management Initial Comment: When opening the list membership management view in the admin interface, a notice about hitting a bug in 2.1.7 appears. The error log has some more information: admin(31507): [----- Mailman Version: 2.1.7 -----] admin(31507): [----- Traceback ------] admin(31507): Traceback (most recent call last): admin(31507): File "/opt/mailman-2.1.7/scripts/driver", line 101, in run_main admin(31507): main() admin(31507): File "/opt/mailman-2.1.7/Mailman/Cgi/admin.py", line 197, in main admin(31507): show_results(mlist, doc, category, subcat, cgidata) admin(31507): File "/opt/mailman-2.1.7/Mailman/Cgi/admin.py", line 497, in show_results admin(31507): form.AddItem(membership_options(mlist, subcat, cgidata, doc, form)) admin(31507): File "/opt/mailman-2.1.7/Mailman/Cgi/admin.py", line 869, in membership_options admin(31507): all = [_m.encode() for _m in mlist.getMembers()] admin(31507): UnicodeError: ASCII decoding error: ordinal not in range(128) admin(31507): [----- Python Information -----] admin(31507): sys.version = 2.2.3 (#1, Nov 11 2003, 17:44:56) [GCC 2.96 20000731 (Red Hat Linux 7.3 2.96-113)] admin(31507): sys.executable = /usr/bin/python2 admin(31507): sys.prefix = /usr admin(31507): sys.exec_prefix = /usr admin(31507): sys.path = /usr admin(31507): sys.platform = linux2 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471487&group_…

1 0

[ mailman-Bugs-1471318 ] Missing Date header in "requires approval" attachment
by SourceForge.net 16 Apr '06

16 Apr '06

Bugs item #1471318, was opened at 2006-04-16 08:22 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Harri Porten (hporten) Assigned to: Nobody/Anonymous (nobody) Summary: Missing Date header in "requires approval" attachment Initial Comment: The message attachment part of the "xxx post from xxx(a)xxx.xx requires approval" mails sent to the list admin are lacking a Date header. The part currently starts with Content-Type: message/rfc822 MIME-Version: 1.0 while RFC822 mandates a Dates header to exist. This is with version 2.1.5 compiled with sources on a Debian 3.1 system. I've seen that the lack of the header has been fixed for other types of mails but not the attachment of this admin mail. Harri. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-04-16 08:50 Message: Logged In: YES user_id=1123998 RFC822 and RFC2822 only address the top level message headers. The standard for the headers of sub-parts in multipart messages is RFC1521. A Date header is not required in the headers of a sub-part. If your issue is that the attached message/rfc822 part itself contains no date header, this is an exact copy of the message received by Mailman. It was up to whatever sent the original message to include a Date: header. If mailman receives a non-compliant message and holds it for approval, it is not up to Mailman to try to correct defects in the received message. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_…

1 0

[ mailman-Bugs-1471318 ] Missing Date header in "requires approval" attachment
by SourceForge.net 16 Apr '06

16 Apr '06

Bugs item #1471318, was opened at 2006-04-16 17:22 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Harri Porten (hporten) Assigned to: Nobody/Anonymous (nobody) Summary: Missing Date header in "requires approval" attachment Initial Comment: The message attachment part of the "xxx post from xxx(a)xxx.xx requires approval" mails sent to the list admin are lacking a Date header. The part currently starts with Content-Type: message/rfc822 MIME-Version: 1.0 while RFC822 mandates a Dates header to exist. This is with version 2.1.5 compiled with sources on a Debian 3.1 system. I've seen that the lack of the header has been fixed for other types of mails but not the attachment of this admin mail. Harri. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1471318&group_…

1 0

[ mailman-Patches-1086319 ] bin/show_qfiles is terminated by exception
by SourceForge.net 16 Apr '06

16 Apr '06

Patches item #1086319, was opened at 2004-12-16 01:10 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1086319&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: command line scripts Group: Mailman 2.1 >Status: Pending >Resolution: Fixed Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Nobody/Anonymous (nobody) Summary: bin/show_qfiles is terminated by exception Initial Comment: Shunted queue files may cause exceptions while bin/show_qfiles is running. By this patch, show_qfiles will show tracebacks and continue processing files. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-04-16 08:02 Message: Logged In: YES user_id=1123998 I think the underlying problem is Bug # 1444447 which is fixed in a different way in Mailman 2.1.8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1086319&group_…

1 0

[ mailman-Patches-1471258 ] OpenLDAP shell backend
by SourceForge.net 16 Apr '06

16 Apr '06

Patches item #1471258, was opened at 2006-04-16 20:10 Message generated for change (Comment added) made by hatukanezumi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1471258&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None >Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Nobody/Anonymous (nobody) Summary: OpenLDAP shell backend Initial Comment: This is a wrapper of Mailman for slapd-shell(5) OpenLDAP shell backend interface. Requirement: o OpenLDAP 2.x o python-ldap o Mailman 2.x, of course:). Installation: 1. Extract tarball. Place shellbe.py and dumpschema.py into $prefix/bin, and mailman-list.schema appropriate location. Give shellbe.py exec permission. 2. Add schema. Insert following line into slapd.conf: include /the/location/of/mailman-list.schema Add database suffix. Insert following lines into slapd.conf: database shell suffix "ou=Lists,o=My Organization,c=AQ" add /usr/local/mailman/bin/shellbe.py delete /usr/local/mailman/bin/shellbe.py modify /usr/local/mailman/bin/shellbe.py search /usr/local/mailman/bin/shellbe.py Then restart slapd. 3. Run (as Mailman user or superuser): $ python $prefix/bin/dumpschema.py ldap://ldap.host/ bind-DN bind-password After that, you shall find schemacache.pck in $varprefix/data directory. 4. Setup mailman. Insert following lines in $prefix/Mailman/mm_cfg.py: SLAPD_SHELL_SUFFIX = 'ou=Lists,o=My Organization,c=AQ' SLAPD_SHELL_OBJECTCLASSES = ['top', 'someStructuralObjectClass', ] Note: o SEARCH doesn't process search filter. Either '(objectClass=*)' or '(objectClass=gnummList)' will be recognized. o User of slapd (typically 'ldap') should be belonged to Mailman group ('mailman'). ---------------------------------------------------------------------- >Comment By: Hatuka*nezumi (hatukanezumi) Date: 2006-04-16 20:27 Message: Logged In: YES user_id=529503 Additional Note: o List member informations (memberships, real names, delivery statuses etc.) aren't supported by this wrapper. Such data will be handled by LDAP membership adapotor (see patch #871062). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1471258&group_…

1 0

[ mailman-Patches-1471258 ] OpenLDAP shell backend
by SourceForge.net 16 Apr '06

16 Apr '06

Patches item #1471258, was opened at 2006-04-16 20:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1471258&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Nobody/Anonymous (nobody) Summary: OpenLDAP shell backend Initial Comment: This is a wrapper of Mailman for slapd-shell(5) OpenLDAP shell backend interface. Requirement: o OpenLDAP 2.x o python-ldap o Mailman 2.x, of course:). Installation: 1. Extract tarball. Place shellbe.py and dumpschema.py into $prefix/bin, and mailman-list.schema appropriate location. Give shellbe.py exec permission. 2. Add schema. Insert following line into slapd.conf: include /the/location/of/mailman-list.schema Add database suffix. Insert following lines into slapd.conf: database shell suffix "ou=Lists,o=My Organization,c=AQ" add /usr/local/mailman/bin/shellbe.py delete /usr/local/mailman/bin/shellbe.py modify /usr/local/mailman/bin/shellbe.py search /usr/local/mailman/bin/shellbe.py Then restart slapd. 3. Run (as Mailman user or superuser): $ python $prefix/bin/dumpschema.py ldap://ldap.host/ bind-DN bind-password After that, you shall find schemacache.pck in $varprefix/data directory. 4. Setup mailman. Insert following lines in $prefix/Mailman/mm_cfg.py: SLAPD_SHELL_SUFFIX = 'ou=Lists,o=My Organization,c=AQ' SLAPD_SHELL_OBJECTCLASSES = ['top', 'someStructuralObjectClass', ] Note: o SEARCH doesn't process search filter. Either '(objectClass=*)' or '(objectClass=gnummList)' will be recognized. o User of slapd (typically 'ldap') should be belonged to Mailman group ('mailman'). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1471258&group_…

1 0

[ mailman-Bugs-1462091 ] admin links force me to insecure mode with password
by SourceForge.net 14 Apr '06

14 Apr '06

Bugs item #1462091, was opened at 03/31/06 05:24 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462091&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: security/privacy Group: 2.1 (stable) >Status: Closed Resolution: Invalid Priority: 5 Submitted By: Trent Larson (trentlarson) Assigned to: Nobody/Anonymous (nobody) Summary: admin links force me to insecure mode with password Initial Comment: I start out in secure mode when I administer my list, but many operations have hard-coded links to HTTP, and then it loses my session information and requires me to login again from that insecure page. In other words, there are many screens that I cannot use without logging in insecurely. Using v 2.1.6. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 04/14/06 19:21 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 03/31/06 08:56 Message: Logged In: YES user_id=1123998 This is not a bug. It is a misconfiguration. What you want to do is put DEFAULT_URL_PATTERN = 'https://%s/mailman/' in mm_cfg.py and then run bin/fix_url.py to update your existing lists, e.g. bin/withlist -l -a -r fix_url -- [fix_url options] but first run bin/fix_url.py stand alone for help. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462091&group_…

1 0

[ mailman-Bugs-1461054 ] Wrong domain used in moderation message
by SourceForge.net 14 Apr '06

14 Apr '06

Bugs item #1461054, was opened at 2006-03-29 16:44 Message generated for change (Comment added) made by brouhaha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461054&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 2.1 (stable) >Status: Closed Resolution: None Priority: 5 Submitted By: Eric Smith (brouhaha) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong domain used in moderation message Initial Comment: Mailman 2.1.7 is running on host foo.example.com, with a mailing list on virtual domain bar.example.com. If a posting will be moderated, an email is sent to the poster offering a chance to cancel the message. However, the cancel URL is on foo.example.com, rather than bar.example.com. The cancel URL works, but it exposes the real hostname, whereas it should only show the virtual domain. ---------------------------------------------------------------------- >Comment By: Eric Smith (brouhaha) Date: 2006-04-14 14:25 Message: Logged In: YES user_id=10325 Never mind, I found the problem. I misunderstood your explanation. I don't understand how this particular list got this way, though, as it was created after the virtual domain was set up and other lists on it were working fine with the correct hostname. Oh well. ---------------------------------------------------------------------- Comment By: Eric Smith (brouhaha) Date: 2006-04-14 14:15 Message: Logged In: YES user_id=10325 That is NOT the problem, as can be seen in the attached example of a moderation message. The message header shows that it came from lists.brouhaha.com, which is the correct virtual domain for the list, as configured, but the moderation link in the message has the hostname donnybrook.brouhaha.com, which is the primary hostname of the machine. I confirmed the list configuration using config_list: % ~mailman/bin/config_list -o - test1 | grep ^host_name host_name = 'lists.brouhaha.com' The only occurrence of "donnybrook" in the output of config_list is in a comment: % ~mailman/bin/config_list -o - test1 | grep donnybrook # href="http://donnybrook.brouhaha.com/mailman/admin/test1/archive">Archival (This comment generated by config_list is wrong, which is a defect in config_list.) ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-04-12 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-29 17:14 Message: Logged In: YES user_id=1123998 The most likely cause of this is that the list attribute web_page_url has the foo.example.com host name instead of bar.example.com. This in turn is caused by creating the list with the wrong or the default host. If this is the case, links in the web interface will likely also be to foo.example.com, and the list won't appear on the bar.example.com admin and listinfo overview pages. You can fix this (assuming your VIRTUAL_HOSTS dictionary is correct - add_virtualhost() directives in mm_cfg.py - by running bin/fix_url.py on the list (just run bin/fix_url.py for instructions). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461054&group_…

1 0

[ mailman-Bugs-1461054 ] Wrong domain used in moderation message
by SourceForge.net 14 Apr '06

14 Apr '06

Bugs item #1461054, was opened at 2006-03-29 16:44 Message generated for change (Comment added) made by brouhaha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461054&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 2.1 (stable) >Status: Open Resolution: None Priority: 5 Submitted By: Eric Smith (brouhaha) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong domain used in moderation message Initial Comment: Mailman 2.1.7 is running on host foo.example.com, with a mailing list on virtual domain bar.example.com. If a posting will be moderated, an email is sent to the poster offering a chance to cancel the message. However, the cancel URL is on foo.example.com, rather than bar.example.com. The cancel URL works, but it exposes the real hostname, whereas it should only show the virtual domain. ---------------------------------------------------------------------- >Comment By: Eric Smith (brouhaha) Date: 2006-04-14 14:15 Message: Logged In: YES user_id=10325 That is NOT the problem, as can be seen in the attached example of a moderation message. The message header shows that it came from lists.brouhaha.com, which is the correct virtual domain for the list, as configured, but the moderation link in the message has the hostname donnybrook.brouhaha.com, which is the primary hostname of the machine. I confirmed the list configuration using config_list: % ~mailman/bin/config_list -o - test1 | grep ^host_name host_name = 'lists.brouhaha.com' The only occurrence of "donnybrook" in the output of config_list is in a comment: % ~mailman/bin/config_list -o - test1 | grep donnybrook # href="http://donnybrook.brouhaha.com/mailman/admin/test1/archive">Archival (This comment generated by config_list is wrong, which is a defect in config_list.) ---------------------------------------------------------------------- Comment By: SourceForge Robot (sf-robot) Date: 2006-04-12 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-03-29 17:14 Message: Logged In: YES user_id=1123998 The most likely cause of this is that the list attribute web_page_url has the foo.example.com host name instead of bar.example.com. This in turn is caused by creating the list with the wrong or the default host. If this is the case, links in the web interface will likely also be to foo.example.com, and the list won't appear on the bar.example.com admin and listinfo overview pages. You can fix this (assuming your VIRTUAL_HOSTS dictionary is correct - add_virtualhost() directives in mm_cfg.py - by running bin/fix_url.py on the list (just run bin/fix_url.py for instructions). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461054&group_…

1 0

[ mailman-Bugs-1469962 ] Attachments with ' just hang
by SourceForge.net 14 Apr '06

14 Apr '06

Bugs item #1469962, was opened at 2006-04-13 10:36 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469962&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: cpkevin (xprt5) Assigned to: Nobody/Anonymous (nobody) Summary: Attachments with ' just hang Initial Comment: If someone sends an email with the character ' in the subject or attachment name mailman hangs. after deleting the ' in the attachment name in /usr/local/cpanel/3rdparty/mailman/lists/list_name/digest.mbox the next message is delivered (but this message isn't delivered!) Apr 11 23:04:22 2006 (60899) Uncaught runner exception: need more than 2 values to unpack This was working fine before a recent upgrade with mailman/python and still works fine on other servers. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-04-14 10:39 Message: Logged In: YES user_id=1123998 I am unable to duplicate this error with various versions of Python's email library. I am using an attachment with the header Content-Disposition: attachment; filename="cal'dar.doc" If the one that fails in your case is different from this in any significant way, please post it. ---------------------------------------------------------------------- Comment By: cpkevin (xprt5) Date: 2006-04-14 06:07 Message: Logged In: YES user_id=1501592 Here is the latest traceback Apr 11 23:04:22 2006 (60899) Uncaught runner exception: need more than 2 values to unpack Apr 11 23:04:22 2006 (60899) Traceback (most recent call last): File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/ToDigest.py", line 92, in process send_digests(mlist, mboxfp) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/ToDigest.py", line 133, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/ToDigest.py", line 315, in send_i18n_digests msg = scrubber(mlist, msg) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/Scrubber.py", line 299, in process url = save_attachment(mlist, part, dir) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/Scrubber.py", line 411, in save_attachment filename = Utils.oneline(msg.get_filename(''), lcset) File "/usr/local/cpanel/3rdparty/mailman/pythonlib/email/Message.py", line 724, in get_filename filename = self.get_param('filename', missing, 'content-disposition') File "/usr/local/cpanel/3rdparty/mailman/pythonlib/email/Message.py", line 607, in get_param for k, v in self._get_params_preserve(failobj, header): File "/usr/local/cpanel/3rdparty/mailman/pythonlib/email/Message.py", line 554, in _get_params_preserve params = Utils.decode_params(params) File "/usr/local/cpanel/3rdparty/mailman/pythonlib/email/Utils.py", line 337, in decode_params charset, language, value = decode_rfc2231(EMPTYSTRING.join(value)) File "/usr/local/cpanel/3rdparty/mailman/pythonlib/email/Utils.py", line 284, in decode_rfc2231 charset, language, s = parts ValueError: need more than 2 values to unpack Apr 11 23:04:22 2006 (60899) SHUNTING: 1144789462.1552839+7ff91a627d48daa19efc8509d86eb3ec869fc909 ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-13 20:34 Message: Logged In: YES user_id=1123998 I'm not sure if this is a 2.1.6 bug or a cPanel bug, but it seems to be fine in 2.1.7 since I have now received copies of this bug report, its two updates, the 149967 report and its update (a total of 5 messages) from the mailman-coders(a)python.org Mailman 2.1.7 list, and they all have subject [ mailman-Bugs-1469962 ] Attachments with ' just hang (or the same with 1469967). I.e., the same messages you receive directly from sourceforge.net are also posted to mailman-coders(a)python.org. In any case, if you want to post the full traceback from the error, either here or directly to me, I will try to determine the problem and suggest a fix for 2.1.6. ---------------------------------------------------------------------- Comment By: cpkevin (xprt5) Date: 2006-04-13 19:22 Message: Logged In: YES user_id=1501592 Mailman version is 2.1.6 ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-13 18:36 Message: Logged In: YES user_id=1123998 What Mailman/Python version is this? Also see http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.011.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469962&group_…

1 0

[ mailman-Bugs-1469962 ] Attachments with ' just hang
by SourceForge.net 14 Apr '06

14 Apr '06

Bugs item #1469962, was opened at 2006-04-13 12:36 Message generated for change (Comment added) made by xprt5 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469962&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: cpkevin (xprt5) Assigned to: Nobody/Anonymous (nobody) Summary: Attachments with ' just hang Initial Comment: If someone sends an email with the character ' in the subject or attachment name mailman hangs. after deleting the ' in the attachment name in /usr/local/cpanel/3rdparty/mailman/lists/list_name/digest.mbox the next message is delivered (but this message isn't delivered!) Apr 11 23:04:22 2006 (60899) Uncaught runner exception: need more than 2 values to unpack This was working fine before a recent upgrade with mailman/python and still works fine on other servers. ---------------------------------------------------------------------- >Comment By: cpkevin (xprt5) Date: 2006-04-14 08:07 Message: Logged In: YES user_id=1501592 Here is the latest traceback Apr 11 23:04:22 2006 (60899) Uncaught runner exception: need more than 2 values to unpack Apr 11 23:04:22 2006 (60899) Traceback (most recent call last): File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/IncomingRunner.py", line 130, in _dispose more = self._dopipeline(mlist, msg, msgdata, pipeline) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Queue/IncomingRunner.py", line 153, in _dopipeline sys.modules[modname].process(mlist, msg, msgdata) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/ToDigest.py", line 92, in process send_digests(mlist, mboxfp) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/ToDigest.py", line 133, in send_digests send_i18n_digests(mlist, mboxfp) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/ToDigest.py", line 315, in send_i18n_digests msg = scrubber(mlist, msg) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/Scrubber.py", line 299, in process url = save_attachment(mlist, part, dir) File "/usr/local/cpanel/3rdparty/mailman/Mailman/Handlers/Scrubber.py", line 411, in save_attachment filename = Utils.oneline(msg.get_filename(''), lcset) File "/usr/local/cpanel/3rdparty/mailman/pythonlib/email/Message.py", line 724, in get_filename filename = self.get_param('filename', missing, 'content-disposition') File "/usr/local/cpanel/3rdparty/mailman/pythonlib/email/Message.py", line 607, in get_param for k, v in self._get_params_preserve(failobj, header): File "/usr/local/cpanel/3rdparty/mailman/pythonlib/email/Message.py", line 554, in _get_params_preserve params = Utils.decode_params(params) File "/usr/local/cpanel/3rdparty/mailman/pythonlib/email/Utils.py", line 337, in decode_params charset, language, value = decode_rfc2231(EMPTYSTRING.join(value)) File "/usr/local/cpanel/3rdparty/mailman/pythonlib/email/Utils.py", line 284, in decode_rfc2231 charset, language, s = parts ValueError: need more than 2 values to unpack Apr 11 23:04:22 2006 (60899) SHUNTING: 1144789462.1552839+7ff91a627d48daa19efc8509d86eb3ec869fc909 ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-13 22:34 Message: Logged In: YES user_id=1123998 I'm not sure if this is a 2.1.6 bug or a cPanel bug, but it seems to be fine in 2.1.7 since I have now received copies of this bug report, its two updates, the 149967 report and its update (a total of 5 messages) from the mailman-coders(a)python.org Mailman 2.1.7 list, and they all have subject [ mailman-Bugs-1469962 ] Attachments with ' just hang (or the same with 1469967). I.e., the same messages you receive directly from sourceforge.net are also posted to mailman-coders(a)python.org. In any case, if you want to post the full traceback from the error, either here or directly to me, I will try to determine the problem and suggest a fix for 2.1.6. ---------------------------------------------------------------------- Comment By: cpkevin (xprt5) Date: 2006-04-13 21:22 Message: Logged In: YES user_id=1501592 Mailman version is 2.1.6 ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-13 20:36 Message: Logged In: YES user_id=1123998 What Mailman/Python version is this? Also see http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.011.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469962&group_…

1 0

[ mailman-Bugs-1469962 ] Attachments with ' just hang
by SourceForge.net 13 Apr '06

13 Apr '06

Bugs item #1469962, was opened at 2006-04-13 10:36 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469962&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: cpkevin (xprt5) Assigned to: Nobody/Anonymous (nobody) Summary: Attachments with ' just hang Initial Comment: If someone sends an email with the character ' in the subject or attachment name mailman hangs. after deleting the ' in the attachment name in /usr/local/cpanel/3rdparty/mailman/lists/list_name/digest.mbox the next message is delivered (but this message isn't delivered!) Apr 11 23:04:22 2006 (60899) Uncaught runner exception: need more than 2 values to unpack This was working fine before a recent upgrade with mailman/python and still works fine on other servers. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-04-13 20:34 Message: Logged In: YES user_id=1123998 I'm not sure if this is a 2.1.6 bug or a cPanel bug, but it seems to be fine in 2.1.7 since I have now received copies of this bug report, its two updates, the 149967 report and its update (a total of 5 messages) from the mailman-coders(a)python.org Mailman 2.1.7 list, and they all have subject [ mailman-Bugs-1469962 ] Attachments with ' just hang (or the same with 1469967). I.e., the same messages you receive directly from sourceforge.net are also posted to mailman-coders(a)python.org. In any case, if you want to post the full traceback from the error, either here or directly to me, I will try to determine the problem and suggest a fix for 2.1.6. ---------------------------------------------------------------------- Comment By: cpkevin (xprt5) Date: 2006-04-13 19:22 Message: Logged In: YES user_id=1501592 Mailman version is 2.1.6 ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-13 18:36 Message: Logged In: YES user_id=1123998 What Mailman/Python version is this? Also see http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.011.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469962&group_…

1 0

[ mailman-Bugs-1469962 ] Attachments with ' just hang
by SourceForge.net 13 Apr '06

13 Apr '06

Bugs item #1469962, was opened at 2006-04-13 12:36 Message generated for change (Comment added) made by xprt5 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469962&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: cpkevin (xprt5) Assigned to: Nobody/Anonymous (nobody) Summary: Attachments with ' just hang Initial Comment: If someone sends an email with the character ' in the subject or attachment name mailman hangs. after deleting the ' in the attachment name in /usr/local/cpanel/3rdparty/mailman/lists/list_name/digest.mbox the next message is delivered (but this message isn't delivered!) Apr 11 23:04:22 2006 (60899) Uncaught runner exception: need more than 2 values to unpack This was working fine before a recent upgrade with mailman/python and still works fine on other servers. ---------------------------------------------------------------------- >Comment By: cpkevin (xprt5) Date: 2006-04-13 21:22 Message: Logged In: YES user_id=1501592 Mailman version is 2.1.6 ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-04-13 20:36 Message: Logged In: YES user_id=1123998 What Mailman/Python version is this? Also see http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.011.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469962&group_…

1 0

[ mailman-Bugs-1469962 ] Attachments with ' just hang
by SourceForge.net 13 Apr '06

13 Apr '06

Bugs item #1469962, was opened at 2006-04-13 10:36 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469962&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: cpkevin (xprt5) Assigned to: Nobody/Anonymous (nobody) Summary: Attachments with ' just hang Initial Comment: If someone sends an email with the character ' in the subject or attachment name mailman hangs. after deleting the ' in the attachment name in /usr/local/cpanel/3rdparty/mailman/lists/list_name/digest.mbox the next message is delivered (but this message isn't delivered!) Apr 11 23:04:22 2006 (60899) Uncaught runner exception: need more than 2 values to unpack This was working fine before a recent upgrade with mailman/python and still works fine on other servers. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-04-13 18:36 Message: Logged In: YES user_id=1123998 What Mailman/Python version is this? Also see http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq06.011.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469962&group_…

1 0

[ mailman-Bugs-1469967 ] Attachments with ' just hang
by SourceForge.net 13 Apr '06

13 Apr '06

Bugs item #1469967, was opened at 2006-04-13 10:49 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469967&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) >Status: Deleted >Resolution: Duplicate Priority: 5 Submitted By: cpkevin (xprt5) Assigned to: Nobody/Anonymous (nobody) Summary: Attachments with ' just hang Initial Comment: If someone sends an email with the character ' in the subject or attachment name mailman hangs. after deleting the ' in the attachment name in /usr/local/cpanel/3rdparty/mailman/lists/list_name/digest.mbox the next message is delivered (but this message isn't delivered!) Apr 11 23:04:22 2006 (60899) Uncaught runner exception: need more than 2 values to unpack This was working fine before a recent upgrade with mailman/python and still works fine on other servers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469967&group_…

1 0

[ mailman-Bugs-1469967 ] Attachments with ' just hang
by SourceForge.net 13 Apr '06

13 Apr '06

Bugs item #1469967, was opened at 2006-04-13 12:49 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469967&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: cpkevin (xprt5) Assigned to: Nobody/Anonymous (nobody) Summary: Attachments with ' just hang Initial Comment: If someone sends an email with the character ' in the subject or attachment name mailman hangs. after deleting the ' in the attachment name in /usr/local/cpanel/3rdparty/mailman/lists/list_name/digest.mbox the next message is delivered (but this message isn't delivered!) Apr 11 23:04:22 2006 (60899) Uncaught runner exception: need more than 2 values to unpack This was working fine before a recent upgrade with mailman/python and still works fine on other servers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469967&group_…

1 0

[ mailman-Bugs-1469962 ] Attachments with ' just hang
by SourceForge.net 13 Apr '06

13 Apr '06

Bugs item #1469962, was opened at 2006-04-13 12:36 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469962&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: mail delivery Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: cpkevin (xprt5) Assigned to: Nobody/Anonymous (nobody) Summary: Attachments with ' just hang Initial Comment: If someone sends an email with the character ' in the subject or attachment name mailman hangs. after deleting the ' in the attachment name in /usr/local/cpanel/3rdparty/mailman/lists/list_name/digest.mbox the next message is delivered (but this message isn't delivered!) Apr 11 23:04:22 2006 (60899) Uncaught runner exception: need more than 2 values to unpack This was working fine before a recent upgrade with mailman/python and still works fine on other servers. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1469962&group_…

1 0

[ mailman-Bugs-1461054 ] Wrong domain used in moderation message
by SourceForge.net 12 Apr '06

12 Apr '06

Bugs item #1461054, was opened at 03/29/06 16:44 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461054&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: 2.1 (stable) >Status: Closed Resolution: None Priority: 5 Submitted By: Eric Smith (brouhaha) Assigned to: Nobody/Anonymous (nobody) Summary: Wrong domain used in moderation message Initial Comment: Mailman 2.1.7 is running on host foo.example.com, with a mailing list on virtual domain bar.example.com. If a posting will be moderated, an email is sent to the poster offering a chance to cancel the message. However, the cancel URL is on foo.example.com, rather than bar.example.com. The cancel URL works, but it exposes the real hostname, whereas it should only show the virtual domain. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 04/12/06 19:20 Message: Logged In: YES user_id=1312539 This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 03/29/06 17:14 Message: Logged In: YES user_id=1123998 The most likely cause of this is that the list attribute web_page_url has the foo.example.com host name instead of bar.example.com. This in turn is caused by creating the list with the wrong or the default host. If this is the case, links in the web interface will likely also be to foo.example.com, and the list won't appear on the bar.example.com admin and listinfo overview pages. You can fix this (assuming your VIRTUAL_HOSTS dictionary is correct - add_virtualhost() directives in mm_cfg.py - by running bin/fix_url.py on the list (just run bin/fix_url.py for instructions). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1461054&group_…

1 0

[ mailman-Feature Requests-1469343 ] Per-user Reply-To mungling for sent mails
by SourceForge.net 12 Apr '06

12 Apr '06

Feature Requests item #1469343, was opened at 2006-04-12 15:16 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1469343&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Timo Sirainen (cras) Assigned to: Nobody/Anonymous (nobody) Summary: Per-user Reply-To mungling for sent mails Initial Comment: This feature request isn't the same as the existing ones about per-user reply-to mungling (eg. 788314). I like the ability for users to be able to select if they want to get both private and list replies (highly useful in big traffic lists) or only list replies (if you're going to read all the mails in the list anyway). Now this is already possible assuming that everyone hits Reply-to-all, which I think is what most people do. However for those who want only the list replies, they need to set "Reply-To: list" header for their own mails. This is impossible or difficult to configure to be automatic in most email clients. So, a user-specific option to specify if the Reply-To header should be added to mails the user himself sends would be nice. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1469343&group_…

1 0

[ mailman-Patches-1469076 ] Updated Vietnamese translation 2.1.8rc1
by SourceForge.net 12 Apr '06

12 Apr '06

Patches item #1469076, was opened at 2006-04-12 17:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1469076&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: internationalization Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Clytie Siddall (clytie) Assigned to: Nobody/Anonymous (nobody) Summary: Updated Vietnamese translation 2.1.8rc1 Initial Comment: Here's the updated translation. :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1469076&group_…

1 0

[ mailman-Patches-1464767 ] XMLRPC patch for Mailman 2.1.7
by SourceForge.net 05 Apr '06

05 Apr '06

Patches item #1464767, was opened at 2006-04-05 10:43 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1464767&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Rafal Krzewski (rkrzewsk) Assigned to: Nobody/Anonymous (nobody) Summary: XMLRPC patch for Mailman 2.1.7 Initial Comment: The patch is based on the work of Joshua Ginsberg and Joseph Tate hosted at http://savannah.nongnu.org/projects/mailman-xmlrpc/ + modifications developed by Caltha: - New methods added to the interface: getLocales, getPendingMessages, getPendingSubscriptions, getNewPendingTasks, getPendingTask, getPendingTaskType, handleModerationRequest, postmessage (documentation included in the respective methods) - XMLRPC.py was split into XMLRPCHandler class, XMPRPC (CGI server endpoint), StandaloneXMLRPC (standalone/daemon server endpoint) - added configuration option for performing site admin authentication on all methods. By default the methods operating on a specific list require list admin authentication. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1464767&group_…

1 0

[ mailman-Patches-1463918 ] Make password mailing RFC 3834 compliant
by SourceForge.net 03 Apr '06

03 Apr '06

Patches item #1463918, was opened at 2006-04-03 17:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1463918&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Kyle VanderBeek (kylev) Assigned to: Nobody/Anonymous (nobody) Summary: Make password mailing RFC 3834 compliant Initial Comment: RFC 3834 specifies that messages generated automatically by periodic automatic jobs should contain an Auto-Submitted header with a 'auto-generated' value; a 1-line patch does this for the cron'ed month membership reminder. This helps avoid loops and potential "sorcerers apprentice mode" when hitting well mannered vaction programs that recognize RFC 3834 headers. There is probably more work to do in mailman related to this RFC, as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1463918&group_…

1 0

[ mailman-Bugs-1462479 ] mailman 2.1.7 not on ftp.gnu.org
by SourceForge.net 03 Apr '06

03 Apr '06

Bugs item #1462479, was opened at 2006-03-31 18:57 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462479&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: karl berry (kberry) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: mailman 2.1.7 not on ftp.gnu.org Initial Comment: the web page on list.org says that the current version of mailman is downloadable from GNU, but ftp.gnu.org doesn't actually have 2.1.7 (or 2.1.6). >From the lack of .sig files in ftp.gnu.org/gnu/mailman, I surmise your gpg keys may never have gotten registered by sysadmin to enable ftp uploads. here's the bit from maintain.texi about that procedure in case it helps: http://www.gnu.org/prep/maintain/html_node/Automated-FTP-Uploads.html Best, Karl ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-03 11:14 Message: Logged In: YES user_id=12800 I've sent a new registration message to ftp-upload, with Tokio's key. Assigning this one to him so he can try to do an upload when we get a response. ---------------------------------------------------------------------- Comment By: karl berry (kberry) Date: 2006-04-01 20:07 Message: Logged In: YES user_id=33248 Hi Barry, The only way to check is to try an upload and see if it works. Since you were registered once, I know of no reason why you would have been de-registered. If it fails, I guess you should mail ftp-upload(a)gnu.org with the info from maintain.texi (which translates to GNU sysadmin). Ditto for getting Tokio registered. Regards, k ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-01 19:55 Message: Logged In: YES user_id=12800 At one point, my GPG key was definitely registered since I've done uploads of mailman before. I guess we should try to get Tokio registered too so he can do file uploads (I'll still have to do the ones to list.org) Is there a way to check whether my key is registered, or may have gotten lost? Or should I just re-register them? BTW, my pubkeys are always available at http://barry.warsaw.us ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462479&group_…

1 0

[ mailman-Bugs-1462479 ] mailman 2.1.7 not on ftp.gnu.org
by SourceForge.net 01 Apr '06

01 Apr '06

Bugs item #1462479, was opened at 2006-03-31 23:57 Message generated for change (Comment added) made by kberry You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462479&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: karl berry (kberry) Assigned to: Nobody/Anonymous (nobody) Summary: mailman 2.1.7 not on ftp.gnu.org Initial Comment: the web page on list.org says that the current version of mailman is downloadable from GNU, but ftp.gnu.org doesn't actually have 2.1.7 (or 2.1.6). >From the lack of .sig files in ftp.gnu.org/gnu/mailman, I surmise your gpg keys may never have gotten registered by sysadmin to enable ftp uploads. here's the bit from maintain.texi about that procedure in case it helps: http://www.gnu.org/prep/maintain/html_node/Automated-FTP-Uploads.html Best, Karl ---------------------------------------------------------------------- >Comment By: karl berry (kberry) Date: 2006-04-02 01:07 Message: Logged In: YES user_id=33248 Hi Barry, The only way to check is to try an upload and see if it works. Since you were registered once, I know of no reason why you would have been de-registered. If it fails, I guess you should mail ftp-upload(a)gnu.org with the info from maintain.texi (which translates to GNU sysadmin). Ditto for getting Tokio registered. Regards, k ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-02 00:55 Message: Logged In: YES user_id=12800 At one point, my GPG key was definitely registered since I've done uploads of mailman before. I guess we should try to get Tokio registered too so he can do file uploads (I'll still have to do the ones to list.org) Is there a way to check whether my key is registered, or may have gotten lost? Or should I just re-register them? BTW, my pubkeys are always available at http://barry.warsaw.us ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462479&group_…

1 0

[ mailman-Bugs-1462479 ] mailman 2.1.7 not on ftp.gnu.org
by SourceForge.net 01 Apr '06

01 Apr '06

Bugs item #1462479, was opened at 2006-03-31 18:57 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462479&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: karl berry (kberry) Assigned to: Nobody/Anonymous (nobody) Summary: mailman 2.1.7 not on ftp.gnu.org Initial Comment: the web page on list.org says that the current version of mailman is downloadable from GNU, but ftp.gnu.org doesn't actually have 2.1.7 (or 2.1.6). >From the lack of .sig files in ftp.gnu.org/gnu/mailman, I surmise your gpg keys may never have gotten registered by sysadmin to enable ftp uploads. here's the bit from maintain.texi about that procedure in case it helps: http://www.gnu.org/prep/maintain/html_node/Automated-FTP-Uploads.html Best, Karl ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-04-01 19:55 Message: Logged In: YES user_id=12800 At one point, my GPG key was definitely registered since I've done uploads of mailman before. I guess we should try to get Tokio registered too so he can do file uploads (I'll still have to do the ones to list.org) Is there a way to check whether my key is registered, or may have gotten lost? Or should I just re-register them? BTW, my pubkeys are always available at http://barry.warsaw.us ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1462479&group_…

1 0