Mailman 3 September 2004 - Mailman-coders

[ mailman-Patches-872068 ] Decorate.py patch
by SourceForge.net 18 Sep '04

18 Sep '04

Patches item #872068, was opened at 2004-01-07 00:46 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=872068&group_i… Category: internationalization Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 7 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Decorate.py patch Initial Comment: Here is a patch which was defered and not included in 2.1.4 for Decorate.py. This fixes most of the footer-in-the-attachment problem by 1. convert header, body and footer into unicode 2. then concatnate them 3. try encode with the list charset 4. if fail, encode with the message charset 5. if both attempts fail, make the footer attachment. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-18 08:41 Message: Logged In: YES user_id=67709 committed (new revision: 2.21.2.4) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=872068&group_i…

1 0

[ mailman-Bugs-1030228 ] Mass Subscribe address with control character - can't delete
by SourceForge.net 18 Sep '04

18 Sep '04

Bugs item #1030228, was opened at 2004-09-18 01:28 Message generated for change (Comment added) made by spot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_… Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Nobody/Anonymous (nobody) Summary: Mass Subscribe address with control character - can't delete Initial Comment: Mailman 2.1.4 We mass subscribed an automatically generated list of addresses. One of these contained an ascii Vertical-Tab character. The (somewhat munged for privacy) address in the mass subscribe list was lauxxxxxher(a)comcast.net<VT>rixxxxxher where <VT> represents ascii Vertical Tab (hex 0B). The address was subscribed OK and then noticed to be bad. We followed the link from the member list to that member's option page an attempted to unsubscribe it and "encountered a bug". This happened twice in succession and then a third time about an hour later. The error log entry from the first try is attached (with the same address munging). Another list administrator tried the same thing the next morning and that time it worked. We don't know why what we think was the same unsubscribe procedure didn't work 3 times and then worked the next day. the following is in Utils.py # TBD: what other characters should be disallowed? _badchars = re.compile(r'[][()<>|;^,/\200-\377]') A fix might be to add the range \000-\037 to the _badchars re, but this may not be correct. It is not clear whether they should be allowed. RFC 2822 allows "non white space" control characters in domain-literals, but not in local-parts of addresses. However, RFC 2821 (SMTP) says: A domain (or domain name) consists of one or more dot-separated components. These components ("labels" in DNS terminology) are restricted for SMTP purposes to consist of a sequence of letters, digits, and hyphens drawn from the ASCII character set. Thus, it seems that for Mailman purposes it would be safe to not allow any of \000-\037 in addresses. ---------------------------------------------------------------------- Comment By: Terri Oda (spot) Date: 2004-09-18 01:54 Message: Logged In: YES user_id=110886 As a side note, if you have problems with illegal characters in subscribed addresses, here's the relevant FAQ entry: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.013.htp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_…

1 0

[ mailman-Bugs-1030228 ] Mass Subscribe address with control character - can't delete
by SourceForge.net 18 Sep '04

18 Sep '04

Bugs item #1030228, was opened at 2004-09-17 22:28 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=1030228&group_… Category: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Nobody/Anonymous (nobody) Summary: Mass Subscribe address with control character - can't delete Initial Comment: Mailman 2.1.4 We mass subscribed an automatically generated list of addresses. One of these contained an ascii Vertical-Tab character. The (somewhat munged for privacy) address in the mass subscribe list was lauxxxxxher(a)comcast.net<VT>rixxxxxher where <VT> represents ascii Vertical Tab (hex 0B). The address was subscribed OK and then noticed to be bad. We followed the link from the member list to that member's option page an attempted to unsubscribe it and "encountered a bug". This happened twice in succession and then a third time about an hour later. The error log entry from the first try is attached (with the same address munging). Another list administrator tried the same thing the next morning and that time it worked. We don't know why what we think was the same unsubscribe procedure didn't work 3 times and then worked the next day. the following is in Utils.py # TBD: what other characters should be disallowed? _badchars = re.compile(r'[][()<>|;^,/\200-\377]') A fix might be to add the range \000-\037 to the _badchars re, but this may not be correct. It is not clear whether they should be allowed. RFC 2822 allows "non white space" control characters in domain-literals, but not in local-parts of addresses. However, RFC 2821 (SMTP) says: A domain (or domain name) consists of one or more dot-separated components. These components ("labels" in DNS terminology) are restricted for SMTP purposes to consist of a sequence of letters, digits, and hyphens drawn from the ASCII character set. Thus, it seems that for Mailman purposes it would be safe to not allow any of \000-\037 in addresses. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1030228&group_…

1 0

[ mailman-Patches-891491 ] Scrubber.py patch
by SourceForge.net 17 Sep '04

17 Sep '04

Patches item #891491, was opened at 2004-02-06 01:26 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=891491&group_i… Category: Pipermail Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 8 Submitted By: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Scrubber.py patch Initial Comment: Scrubber.py has number of bugs for processing various types of attachment and languages and many have submitted patches to fix them. This patch item is opened to collect such patches for convenience. This patch corrects: - if an attached text is composed by win notepad, it has no charset specified and actual charset may be different from message/list charset. This sometimes cause error in composing digest message. - sometimes, null charset is represented by '' as well as None. - embedded rfc-2822 message is lost if you don't use msg.walk() - special problem with japanese charsets. - t (stringfied part) may be None which you can't append a '\n'. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-17 03:02 Message: Logged In: YES user_id=67709 Merged in CVS. Defaults.py.in new revision: 2.112.2.17; Scrubber.py new revision: 2.18.2.7; ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-09-15 08:08 Message: Logged In: YES user_id=113859 Maybe that was because I was using my patches for preventing to break the signature, too. Those patches keep the charset lines correct and not reformatted. However that is just a guess. Thanks for testing and fixing the patch. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-14 00:25 Message: Logged In: YES user_id=67709 Your sample email did not reproduce error. Anyway, I managed to make a message which can cause the error and confirmed the last fix was valid. Thank you for your cooperation. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-09-13 18:23 Message: Logged In: YES user_id=113859 The patch looks better, but I probably can only test it when I updated my Mailman patches again. I have directly send you an email that should trigger the bug so you can test. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-11 23:45 Message: Logged In: YES user_id=67709 Sorry for the problem. I have updated this patch (2004-09-12 version) Please try and report this patch because I can't fully reproduce the problem (in Japanese environment). ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-09-11 18:04 Message: Logged In: YES user_id=113859 scrubber.patch 2004-08-24 has a problem. Charset(lcset).output_charset can return None according to the documentation. E.g. when no conversion is needed. This would assign Non to lcset_out . Later this leads to an exception in try: if len(charset) == 0: charset = 'us-ascii' t = t.encode(charset, 'replace') except (UnicodeError, LookupError, ValueError): t = t.encode(lcset, 'replace') because: TypeError: len() of unsized object ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-08-24 07:58 Message: Logged In: YES user_id=67709 added a fix for the case of lcset_out <> lcset. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-04-14 18:53 Message: Logged In: YES user_id=113859 Thanks for working on the patch. ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-02-25 10:42 Message: Logged In: YES user_id=67709 uploading revised patch. Now fixes a few more bugs which try to decode scrub plain text message and result in mojibake. Also, japanese filename tend to become so long that system limit may exceeded because of mime encoding, so add an option not to use the filename in the message but to use 'attachment' as filename. Because this patch spans two files (Defaults.py.in and Handlers/Scrubber.py) you have to cd mailman and patch -p1 < this_patch. (Well, I think it is -p1. If it didn't work, try -p0 ;-) ---------------------------------------------------------------------- Comment By: Jonathan Larmour (jifl) Date: 2004-02-22 17:25 Message: Logged In: YES user_id=817601 I strongly recommend applying this patch. I received a mail bounce on a list with an empty charset in a part (i.e. "charset=") and it caused /var/mailman/cron/senddigest and thus all digest processing to fail because of this error: Traceback (most recent call last): File "/var/mailman/cron/senddigests", line 94, in ? main() File "/var/mailman/cron/senddigests", line 86, in main mlist.send_digest_now() File "/var/mailman/Mailman/Digester.py", line 60, in send_digest_now ToDigest.send_digests(self, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 123, in send_digests send_i18n_digests(mlist, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 295, in send_i18n_digests msg = scrubber(mlist, msg) File "/var/mailman/Mailman/Handlers/Scrubber.py", line 308, in process t = t.encode(charset, 'replace') File "/usr/lib/python2.2/encodings/__init__.py", line 51, in search_function mod = __import__(modname,globals(),locals(),'*') which is something this patch fixes. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=891491&group_i…

1 0

[ mailman-Patches-1029275 ] Maximum number of members per list.
by SourceForge.net 16 Sep '04

16 Sep '04

Patches item #1029275, was opened at 2004-09-16 12:31 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=1029275&group_… Category: list administration Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: iamstratus (iamstratus) Assigned to: Nobody/Anonymous (nobody) Summary: Maximum number of members per list. Initial Comment: With this patch site administrators can control the maximum number of members per list. I really need this feature but it's my first attempt changing mailman code so i don't known if it's the best way to handle this situation and if a list administrator can override 'max_members'.Comments, anyone? I've patched mailman 2.1.5 and the mailman 2.1.5 official debian source package (through dpatch) and it seems to be working fine on my test server. The lists that doesn't have 'max_members'[*] or where it's 0 are unlimited and i've created (based on change_pw) the change_maxmembers script where you can change and print the 'max_members' attribute from a list (or many). [*] = How the new attributes situation is handled? On upgrade you add what's missing with the upgrade script or what? Hope that helps, Gustavo Franco -- <stratus(a)acm.org> RITS - http://www.rits.org.br/ p.s: It's being accepted i guess that we can ack some of the suggestions at the RFE #403310. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1029275&group_…

1 0

[ mailman-Bugs-1028975 ] checkdbs remainders for not existing requests
by SourceForge.net 16 Sep '04

16 Sep '04

Bugs item #1028975, was opened at 2004-09-16 06:40 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=1028975&group_… Category: command line scripts Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Alberto Marconi (albertomarconi) Assigned to: Nobody/Anonymous (nobody) Summary: checkdbs remainders for not existing requests Initial Comment: checkdbs sends remainders to list owners concerning pending requests which do not exist. It happens on new lists which are missing the request.pck file. The count of the pending requests is -1. The NumRequestsPending() function returns -1 if the request.pck file is missing. The following patch correct this problem: --- checkdbs.orig 2004-09-13 18:36:31.000000000 +0200 +++ checkdbs 2004-09-16 05:33:27.000000000 +0200 @@ -96,7 +96,7 @@ del mlist.hold_and_cmd_autoresponses [sender] # Only here have we changed the list's database mlist.Save() - if count: + if count > 0: i18n.set_language(mlist.preferred_language) realname = mlist.real_name text = Utils.maketext( ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1028975&group_…

1 0

[ mailman-Patches-1025372 ] empty Cc:
by SourceForge.net 16 Sep '04

16 Sep '04

Patches item #1025372, was opened at 2004-09-09 20:02 Message generated for change (Settings changed) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1025372&group_… >Category: mail delivery >Group: Mailman 2.1 Status: Open >Resolution: Later Priority: 7 Submitted By: Rob Ellis (robellis) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: empty Cc: Initial Comment: In lists migrated from 2.0.13, new messages without a Cc: header end up with an empty one when delivered by mailman (2.1.5). Freshly created lists don't seem to have the problem ? This is on a freebsd 4 stable machine running postfix 2.0.19,1 with mailman set up to use SMTPDirect. Python 2.3.3. The attached patch to AvoidDuplicates.py/CookHeaders.py seems to fix it... - rob ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-16 01:30 Message: Logged In: YES user_id=67709 Okey, I take this one for testing at my site and merge into CVS if no problem. Looks like the latter part (CookHeaders.py) is unnecessary because at least one cc is registered. ---------------------------------------------------------------------- Comment By: Morgan Fletcher (potstickr) Date: 2004-09-15 23:53 Message: Logged In: YES user_id=459672 Er, spoke too soon. Did a 'mailmanctl restart' and then sent a test message, and did not see an empty cc header. Thanks! ---------------------------------------------------------------------- Comment By: Morgan Fletcher (potstickr) Date: 2004-09-15 23:45 Message: Logged In: YES user_id=459672 I tried this patch on a netbsd machine recently upgraded from 2.0.8 to 2.1.5. After applying the patch and a 'make install' I still see the empty Cc header. This bug is causing some trouble for some our list members, so I was really hoping this fix would work. Let me know if you need debugging info or testing of possible patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1025372&group_…

1 0

[ mailman-Patches-1025372 ] empty Cc:
by SourceForge.net 16 Sep '04

16 Sep '04

Patches item #1025372, was opened at 2004-09-09 20:02 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1025372&group_… >Category: None >Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Rob Ellis (robellis) Assigned to: Nobody/Anonymous (nobody) Summary: empty Cc: Initial Comment: In lists migrated from 2.0.13, new messages without a Cc: header end up with an empty one when delivered by mailman (2.1.5). Freshly created lists don't seem to have the problem ? This is on a freebsd 4 stable machine running postfix 2.0.19,1 with mailman set up to use SMTPDirect. Python 2.3.3. The attached patch to AvoidDuplicates.py/CookHeaders.py seems to fix it... - rob ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-16 01:30 Message: Logged In: YES user_id=67709 Okey, I take this one for testing at my site and merge into CVS if no problem. Looks like the latter part (CookHeaders.py) is unnecessary because at least one cc is registered. ---------------------------------------------------------------------- Comment By: Morgan Fletcher (potstickr) Date: 2004-09-15 23:53 Message: Logged In: YES user_id=459672 Er, spoke too soon. Did a 'mailmanctl restart' and then sent a test message, and did not see an empty cc header. Thanks! ---------------------------------------------------------------------- Comment By: Morgan Fletcher (potstickr) Date: 2004-09-15 23:45 Message: Logged In: YES user_id=459672 I tried this patch on a netbsd machine recently upgraded from 2.0.8 to 2.1.5. After applying the patch and a 'make install' I still see the empty Cc header. This bug is causing some trouble for some our list members, so I was really hoping this fix would work. Let me know if you need debugging info or testing of possible patches. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1025372&group_…

1 0

[ mailman-Patches-970383 ] moderator -1 admin requests pending
by SourceForge.net 16 Sep '04

16 Sep '04

Patches item #970383, was opened at 2004-06-10 13:57 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=970383&group_i… Category: list administration Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: Jim Tittsler (jtittsler) Assigned to: Nobody/Anonymous (nobody) Summary: moderator -1 admin requests pending Initial Comment: ListAdmin.NumRequestsPending() presumes that the request database always has at least one entry... a dummy "request" containing the version number of the request database. bin/newlist does not create a request database for each list, so the moderator gets a daily mail saying there are -1 requests pending. I propose that when __opendb() fails because the file didn't exist, the version number be added to the __db dict. Two additional points: - perhaps __open_db should ALWAYS add the version to the db, in case a request.pck somehow was created without a version key (especially since the version isn't currently checked) - the closedb setting of the version could *probably* be safely removed ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-16 01:06 Message: Logged In: YES user_id=67709 fixed in CVS: revision: 2.41.2.7 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=970383&group_i…

1 0

[ mailman-Patches-665569 ] make Postfix bounce detection work with newer postfix
by SourceForge.net 16 Sep '04

16 Sep '04

Patches item #665569, was opened at 2003-01-10 09:33 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=665569&group_i… Category: bounce processing Group: Mailman 2.1 >Status: Closed Resolution: None Priority: 5 Submitted By: James Henstridge (jhenstridge) Assigned to: Nobody/Anonymous (nobody) Summary: make Postfix bounce detection work with newer postfix Initial Comment: Mailman does not recognise bounce messages from newer versions of Postfix. The content-type header on bounce messages looks like this: Content-Type: multipart/report; report-type=delivery-status; boundary="2892E4C0CF.1042189077/quoll.daa.com.au" Mailman only looks for bounce messages with type multipart/mixed, so skips them. The simple solution is to check for both content types (which should allow mailman to continue to work with old postfixes. The attached patch is against 2.0.x (haven't upgraded to MM2.1 yet), but the code is almost identical for 2.1 so the patch should be easy to apply. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2004-09-16 00:27 Message: Logged In: YES user_id=67709 fixed in the CVS (Postfix.py 2.6.2.2) ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2003-03-16 02:57 Message: Logged In: YES user_id=146903 Not sure if this code is applicable to MM2.1. I guess the generic DSN bounce detection handles it. If there is another MM2.0.x bug fix release, it may be nice to apply. ---------------------------------------------------------------------- Comment By: James Henstridge (jhenstridge) Date: 2003-01-10 09:36 Message: Logged In: YES user_id=146903 Hmm. It seems to have lost the attachment ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=665569&group_i…

1 0