From noreply at sourceforge.net Tue Nov 1 02:33:40 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Oct 2005 17:33:40 -0800 Subject: [ mailman-Bugs-1344305 ] trojan problem Message-ID: Bugs item #1344305, was opened at 2005-10-31 21:30 Message generated for change (Comment added) made by david-powell You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1344305&group_id=103 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: More Information Needed Status: Open Resolution: None Priority: 5 Submitted By: dave the dragon (david-powell) Assigned to: Nobody/Anonymous (nobody) Summary: trojan problem Initial Comment: more a observed comment but may have other implications recently i was running bit defender antivirus on my pc and found it reported /usr/lib/mailman/tests/msgs/nimda.txt=>(IFRAME) infected: Trojan.Exploit.Html.Iframe.Filedownload.AW <- cevakrnl.xmd from what i can gather the file is one used for testing (not shure if the actual exploit code needs to be there for that though) but it raises an issue in that because of the file being included in the distributed code it may cause some distributions from including the whole package in there distributions and may also possibaly in some cercumstances lead to legal action as it may be construded that this trojan code is being distributed just feel that this should be pointed out to you Dave ---------------------------------------------------------------------- >Comment By: dave the dragon (david-powell) Date: 2005-11-01 01:33 Message: Logged In: YES user_id=1175630 ok ty for the info , was just concerned that it may be a problem never had chance to look at the file the checker deleted it Dave ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-10-31 22:17 Message: Logged In: YES user_id=1123998 The file never contained any trojan code. It is safe to look at it and if you do, you'll see that it is mostly MIME headers and a few bits of innocuous content. As of Mailman 2.1.6, the file is no longer in the distribution. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1344305&group_id=103 From noreply at sourceforge.net Tue Nov 1 03:54:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 31 Oct 2005 18:54:25 -0800 Subject: [ mailman-Patches-1343100 ] config_list vs. PEP 263 Message-ID: Patches item #1343100, was opened at 2005-10-31 03:58 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1343100&group_id=103 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: Closed >Resolution: Accepted Priority: 5 Submitted By: Hatuka*nezumi (hatukanezumi) Assigned to: Nobody/Anonymous (nobody) Summary: config_list vs. PEP 263 Initial Comment: As of Python 2.3, DeprecatedWarning is issued for non-US-ASCII source. Let output of bin/config_list be compliant to PEP 263. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-11-01 02:54 Message: Logged In: YES user_id=67709 I've checked this fix and more for the output into CVS. Thanks for reporting this problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1343100&group_id=103 From noreply at sourceforge.net Wed Nov 2 06:15:50 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 01 Nov 2005 21:15:50 -0800 Subject: [ mailman-Bugs-1345599 ] Unsubscribed users continue to receive reminders Message-ID: Bugs item #1345599, was opened at 2005-11-02 05:15 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=1345599&group_id=103 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: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Joe Cooper (swelljoe) Assigned to: Nobody/Anonymous (nobody) Summary: Unsubscribed users continue to receive reminders Initial Comment: I have two machines, one running 2.1.6 (with no patches, as provided by list.org) and another running 2.1.5 (as provided by Fedora Core 4), and both exhibit a very annoying problem when password reminders are enabled. Users who have successfully unsubscribed continue to receive reminders...possibly forever, but at least two monthly reminder cycles is confirmed. I don't know if it always happens, but on a system with about 1000 subscribers across all lists, I get about two or three complaints about this every month, so it seems likely. A search for the user in the membership management list confirms they do not exist as a subscriber. grepping for the address in the Mailman directories turns up the address twice in the lists/list-name/config.db file. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1345599&group_id=103 From noreply at sourceforge.net Thu Nov 3 00:11:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 15:11:26 -0800 Subject: [ mailman-Patches-1246003 ] 2.1.6 senddigests unicode error exception handling Message-ID: Patches item #1246003, was opened at 2005-07-27 13:12 Message generated for change (Comment added) made by polansky You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1246003&group_id=103 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: Auke Kok (sofar) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.6 senddigests unicode error exception handling Initial Comment: Hi, I've had senddigests break on me and this seems to be resolved by adding a proper exception handling as follows: vi +333 Mailman/Handlers/ToDigest.py replace: except LookupError: with: except (UnicodeError, LookupError): after this adjustment all digests are sent out properly again for my lists. symptoms were: 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 133, in send_digests send_i18n_digests(mlist, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 331, in send_i18n_digests payload = unicode(payload, mcset, 'replace' UnicodeError: ISO-2022-JP decoding error: invalid designation ---------------------------------------------------------------------- Comment By: Jonathan Polansky (polansky) Date: 2005-11-02 23:11 Message: Logged In: YES user_id=567517 I just wanted to add that I also ran into this error and this fix seems to have solved the problem. If this could be included in the next mm update, that'd be great. Also, thanks to Auke for the fix! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1246003&group_id=103 From noreply at sourceforge.net Thu Nov 3 00:42:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 15:42:26 -0800 Subject: [ mailman-Bugs-1345599 ] Unsubscribed users continue to receive reminders Message-ID: Bugs item #1345599, was opened at 2005-11-01 21:15 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1345599&group_id=103 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: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Joe Cooper (swelljoe) Assigned to: Nobody/Anonymous (nobody) Summary: Unsubscribed users continue to receive reminders Initial Comment: I have two machines, one running 2.1.6 (with no patches, as provided by list.org) and another running 2.1.5 (as provided by Fedora Core 4), and both exhibit a very annoying problem when password reminders are enabled. Users who have successfully unsubscribed continue to receive reminders...possibly forever, but at least two monthly reminder cycles is confirmed. I don't know if it always happens, but on a system with about 1000 subscribers across all lists, I get about two or three complaints about this every month, so it seems likely. A search for the user in the membership management list confirms they do not exist as a subscriber. grepping for the address in the Mailman directories turns up the address twice in the lists/list-name/config.db file. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-02 15:42 Message: Logged In: YES user_id=1123998 I know your experience seems to contradict this, but cron/mailpasswds only mails to current subscribers. Did you really mean lists/list-name/config.db file? Since Mailman 2.1, the list config/membership is in lists/list-name/config.pck. If you have config.db files, they shouldn't be coming into play at all in Mailman 2.1.x (except in initial upgrade when they are used to create the config.pck). Are the users possibly subscribed to some old, inactive version of the list? In any case, I don't think that a user who is not a current subscriber to 'list at domain' can receive a password reminder for 'list at domain' from 'mailman-owner at domain'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1345599&group_id=103 From noreply at sourceforge.net Thu Nov 3 05:39:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 20:39:13 -0800 Subject: [ mailman-Bugs-1345599 ] Unsubscribed users continue to receive reminders Message-ID: Bugs item #1345599, was opened at 2005-11-02 05:15 Message generated for change (Comment added) made by swelljoe You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1345599&group_id=103 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: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Joe Cooper (swelljoe) Assigned to: Nobody/Anonymous (nobody) Summary: Unsubscribed users continue to receive reminders Initial Comment: I have two machines, one running 2.1.6 (with no patches, as provided by list.org) and another running 2.1.5 (as provided by Fedora Core 4), and both exhibit a very annoying problem when password reminders are enabled. Users who have successfully unsubscribed continue to receive reminders...possibly forever, but at least two monthly reminder cycles is confirmed. I don't know if it always happens, but on a system with about 1000 subscribers across all lists, I get about two or three complaints about this every month, so it seems likely. A search for the user in the membership management list confirms they do not exist as a subscriber. grepping for the address in the Mailman directories turns up the address twice in the lists/list-name/config.db file. ---------------------------------------------------------------------- >Comment By: Joe Cooper (swelljoe) Date: 2005-11-03 04:39 Message: Logged In: YES user_id=32533 Both systems have been upgraded from older versions of Mailman, and they have both config.db and config.pck files. Only the config.db file contains the email addresses in question. There is no "old, inactive version" of any of the lists, but perhaps the upgrades to the 2.1 series mailman did not go as well as I'd assumed (the upgrades happened a very long time ago now--users have just recently started becoming abusive about the monthly barrage of membership reminders, so I needed to do something about it). So, I guess I just need to figure out how to make it stop sending reminders to users in the config.db (strange...I don't get two reminders, even though I'm in both the old and new version of the list). If I have a config.pck file, does that mean I can safely remove the config.db file? I'm unable to find any cronjob configuration that runs this program, I assume it is something that the mailman qrunner server triggers? ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-02 23:42 Message: Logged In: YES user_id=1123998 I know your experience seems to contradict this, but cron/mailpasswds only mails to current subscribers. Did you really mean lists/list-name/config.db file? Since Mailman 2.1, the list config/membership is in lists/list-name/config.pck. If you have config.db files, they shouldn't be coming into play at all in Mailman 2.1.x (except in initial upgrade when they are used to create the config.pck). Are the users possibly subscribed to some old, inactive version of the list? In any case, I don't think that a user who is not a current subscriber to 'list at domain' can receive a password reminder for 'list at domain' from 'mailman-owner at domain'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1345599&group_id=103 From noreply at sourceforge.net Thu Nov 3 06:02:55 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 02 Nov 2005 21:02:55 -0800 Subject: [ mailman-Bugs-1345599 ] Unsubscribed users continue to receive reminders Message-ID: Bugs item #1345599, was opened at 2005-11-01 21:15 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1345599&group_id=103 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: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Joe Cooper (swelljoe) Assigned to: Nobody/Anonymous (nobody) Summary: Unsubscribed users continue to receive reminders Initial Comment: I have two machines, one running 2.1.6 (with no patches, as provided by list.org) and another running 2.1.5 (as provided by Fedora Core 4), and both exhibit a very annoying problem when password reminders are enabled. Users who have successfully unsubscribed continue to receive reminders...possibly forever, but at least two monthly reminder cycles is confirmed. I don't know if it always happens, but on a system with about 1000 subscribers across all lists, I get about two or three complaints about this every month, so it seems likely. A search for the user in the membership management list confirms they do not exist as a subscriber. grepping for the address in the Mailman directories turns up the address twice in the lists/list-name/config.db file. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-02 21:02 Message: Logged In: YES user_id=1123998 "If I have a config.pck file, does that mean I can safely remove the config.db file?" Yes. Do remove it. I doubt it will fix anything, but if it does, I think it would have to be because there is still residue of a pre 2.1 Mailman somewhere on the system. "I'm unable to find any cronjob configuration that runs this program, I assume it is something that the mailman qrunner server triggers?" No. It is not triggered by a qrunner. The actual script is cron/mailpasswds. The standard crontab to be installed is cron/crontab.in. See "man cron" for various places it might be installed. Installation from source requires manual installation of the crontab, e.g., as described in which procedure installs it usually in /var/spool/cron/mailman from where it can be listed with the same command described in the above reference with a '-l' option instead of the crontab.in name. The Fedora rpm may install a slightly different crontab (with a user field) in /etc/cron.d/mailman. ---------------------------------------------------------------------- Comment By: Joe Cooper (swelljoe) Date: 2005-11-02 20:39 Message: Logged In: YES user_id=32533 Both systems have been upgraded from older versions of Mailman, and they have both config.db and config.pck files. Only the config.db file contains the email addresses in question. There is no "old, inactive version" of any of the lists, but perhaps the upgrades to the 2.1 series mailman did not go as well as I'd assumed (the upgrades happened a very long time ago now--users have just recently started becoming abusive about the monthly barrage of membership reminders, so I needed to do something about it). So, I guess I just need to figure out how to make it stop sending reminders to users in the config.db (strange...I don't get two reminders, even though I'm in both the old and new version of the list). If I have a config.pck file, does that mean I can safely remove the config.db file? I'm unable to find any cronjob configuration that runs this program, I assume it is something that the mailman qrunner server triggers? ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-02 15:42 Message: Logged In: YES user_id=1123998 I know your experience seems to contradict this, but cron/mailpasswds only mails to current subscribers. Did you really mean lists/list-name/config.db file? Since Mailman 2.1, the list config/membership is in lists/list-name/config.pck. If you have config.db files, they shouldn't be coming into play at all in Mailman 2.1.x (except in initial upgrade when they are used to create the config.pck). Are the users possibly subscribed to some old, inactive version of the list? In any case, I don't think that a user who is not a current subscriber to 'list at domain' can receive a password reminder for 'list at domain' from 'mailman-owner at domain'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1345599&group_id=103 From noreply at sourceforge.net Thu Nov 3 15:05:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 06:05:06 -0800 Subject: [ mailman-Bugs-1269067 ] e-mail command confirmations should be optional Message-ID: Bugs item #1269067, was opened at 2005-08-24 16:09 Message generated for change (Comment added) made by weitzman You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1269067&group_id=103 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: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: e-mail command confirmations should be optional Initial Comment: When we send an e-mail to change the member's options with a command (e.g. to subscribe/unsubscribe members), the confirmation of the commands should be optionnal. This is useful particularly if we do a php script that sends the commands automatically from a post field. Then the member doesn't need to see all those e-mail commands. This should be an optional command that would disable these confirmations for the whole list and all commands. www.Sympa.org mailing list does this very well. Thank you. Daniel ---------------------------------------------------------------------- Comment By: moshe weitzman (weitzman) Date: 2005-11-03 09:05 Message: Logged In: YES user_id=199362 I too need this. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1269067&group_id=103 From noreply at sourceforge.net Fri Nov 4 02:24:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 17:24:34 -0800 Subject: [ mailman-Bugs-1269067 ] e-mail command confirmations should be optional Message-ID: Bugs item #1269067, was opened at 2005-08-24 13:09 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1269067&group_id=103 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: None Status: Open Resolution: None Priority: 5 Submitted By: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: e-mail command confirmations should be optional Initial Comment: When we send an e-mail to change the member's options with a command (e.g. to subscribe/unsubscribe members), the confirmation of the commands should be optionnal. This is useful particularly if we do a php script that sends the commands automatically from a post field. Then the member doesn't need to see all those e-mail commands. This should be an optional command that would disable these confirmations for the whole list and all commands. www.Sympa.org mailing list does this very well. Thank you. Daniel ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-03 17:24 Message: Logged In: YES user_id=1123998 In general, I think this is a bad idea because it allows anyone to subscribe anyone else to a list by spoofing their email address in an email command. If you really want to open up subscribing without confirmation, that feature is already available. Put ALLOW_OPEN_SUBSCRIBE = Yes in mm_cfg.py and lists will have a None option for subscribe_policy which will allow subscribe without confirmation. ---------------------------------------------------------------------- Comment By: moshe weitzman (weitzman) Date: 2005-11-03 06:05 Message: Logged In: YES user_id=199362 I too need this. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1269067&group_id=103 From noreply at sourceforge.net Fri Nov 4 06:57:54 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 03 Nov 2005 21:57:54 -0800 Subject: [ mailman-Patches-1347962 ] Sibling list: avoid duplicate mail Message-ID: Patches item #1347962, was opened at 2005-11-04 05:57 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=1347962&group_id=103 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: Tokio Kikuchi (tkikuchi) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Sibling list: avoid duplicate mail Initial Comment: This patch enables to avoid sending duplicate mail if other list address is specified in to: or cc: header. - Sibling lists are other mailing lists on this site whose members are excluded from regular delivery if those list addresses appear in To: or Cc: header. - The list addresses should be witten in full mail address format (e.g. mailman at example.com). Do not specify the list address mutually in the sibling list configuration page or those doubled members won't get message. TBD: - Is the terminology 'sibling' appropriate? - Need more comments in the processing code (CalcRecips.py). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1347962&group_id=103 From noreply at sourceforge.net Sun Nov 6 19:25:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Nov 2005 10:25:21 -0800 Subject: [ mailman-Patches-1123383 ] Daily Status Report script... Message-ID: Patches item #1123383, was opened at 2005-02-15 12:14 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1123383&group_id=103 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: Brad Knowles (shub) Assigned to: Nobody/Anonymous (nobody) Summary: Daily Status Report script... Initial Comment: Folks, I quickly whacked together a Daily Status Report script for Mailman (using Bourne shell, not Python ;), and thought that other folks might be interested in seeing it. The basic concept is a program that gets fired off at 23:59 every night, and goes through a variety of log files looking for entries specific to that date, and indicating problems or certain types of activity that might be of interest to someone trying to administer the server. It also does an "ls -la" of /usr/local/mailman/qfiles/*, so that you can see what is in the queue at the time of the running of the script. My concept was that this daily report would get e-mailed to the admin, or posted to a "reports" mailing list, where they could be archived and kept for future reference. The script does not (yet) do any statistics calculations, although it should be relatively easy to hack together some basic stats using awk, sort, etc.... Anyway, I thought I'd share it and let folks take a look at it, and if anyone has any recommended improvements, we can incorporate those and share them back out with everyone. The code is written under a BSD-style license, so if you don't want to contribute any changes back to me, that's okay. Of course, I would prefer that you did, but I leave the choice up to you. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-11-06 10:25 Message: Logged In: YES user_id=1123998 The vette log summary lists posts held for moderation individually under "Other Errors:". The following patch (watch out for wrapped lines) summarizes them by list instead. --- mmdsr 2005-09-29 21:31:33.000000000 -0700 +++ mmdsrx 2005-11-06 08:20:58.835895418 -0800 @@ -415,10 +415,15 @@ echo "------------------------------" >> $TMP $GREP -i 'Posting to a moderated newsgroup' $TMPLOG | $AWK '{ print $6 }' | $SORT | $UNIQ -c | $SORT -nr >> $TMP + echo "" >> $TMP + echo "Post to moderated list (by list):" >> $TMP + echo "------------------------------" >> $TMP + $GREP -i 'Post to moderated list' $TMPLOG | $AWK '{ print $6 }' | $SORT | $UNIQ -c | $SORT -nr >> $TMP + echo "" >> $TMP echo "Other Errors:" >> $TMP echo "------------------------------" >> $TMP - $EGREP -vi '(Post by non-member|suspicious header|message approved|Discarded posting|bulk message discarded|junk message discarded|Message has implicit destination|Posting to a moderated newsgroup|Message discarded, msgid)' $TMPLOG | $SED 's/^.* ([0-9]*) //' | $SORT | $UNIQ -c | $SORT -nr >> $TMP + $EGREP -vi '(Post by non-member|suspicious header|message approved|Discarded posting|bulk message discarded|junk message discarded|Message has implicit destination|Posting to a moderated newsgroup|Post to moderated list|Message discarded, msgid)' $TMPLOG | $SED 's/^.* ([0-9]*) //' | $SORT | $UNIQ -c | $SORT -nr >> $TMP else ---------------------------------------------------------------------- Comment By: Tom G. Christensen (tgc99) Date: 2005-10-19 01:23 Message: Logged In: YES user_id=1159458 ps output on solaris is full of whitespace but a further echo get's rid of it. The lines in the smtp log are sometimes broken up by a newline (right before the msgid) which throws of the summary. Piping it through sed first will rejoin the broken lines. Use $AWK instead of awk. Patch inserted below: --- mmdsr.orig 2005-10-19 09:42:30.000000000 +0200 +++ mmdsr 2005-10-19 09:44:23.000000000 +0200 @@ -203,7 +203,8 @@ # there is an easier cross-platform way to do it, please let me know. ############################################################################### -MYUID=`$PS -o user -p $$ | $TAIL -1` +GRABUID=`$PS -o user -p $$ | $TAIL -1` +MYUID=`echo $GRABUID` RUNAS="mailman" ############################################################################### @@ -254,7 +255,7 @@ $TOUCH $TMPLOG echo "Log file: $LOG" >> $TMP echo "==============================" >> $TMP - $GREP -si "^$DAY [0-9][0-9:]* $YEAR" $LOGDIR/$LOG >> $TMPLOG + $SED -e :a -e '$!N;s/\n //;ta' -e 'P;D' $LOGDIR/$LOG | $GREP -si "^$DAY [0-9][0-9:]* $YEAR" >> $TMPLOG if [ -f "$LOGDIR/${LOG}" ] ; then @@ -264,7 +265,7 @@ echo "Hourly Summary of Posts" >> $TMP echo "-----------------------" >> $TMP - $SED -e 's/^[A-Z][a-z][a-z] *[0-9]* //' -e 's/:.*$//' $TMPLOG | $UNIQ -c | $SORT -n +1 | awk '{ printf( "%8d %02d:00-%02d :59\n", $1, $2, $2 ) }' >> $TMP + $SED -e 's/^[A-Z][a-z][a-z] *[0-9]* //' -e 's/:.*$//' $TMPLOG | $UNIQ -c | $SORT -n +1 | $AWK '{ printf( "%8d %02d:00-%02 d:59\n", $1, $2, $2 ) }' >> $TMP echo "" >> $TMP echo "Post Count by List" >> $TMP @@ -295,7 +296,7 @@ echo "" >> $TMP echo "Hourly Summary of Messages Sent" >> $TMP echo "-------------------------------" >> $TMP - $SED -e 's/^[A-Z][a-z][a-z] *[0-9]* //' -e 's/:.* for / /' -e 's/ recips,.*$//' $TMPLOG | awk '{ val=int($1); sum[val]+=$2 } END { for (i=0; i<24; i++) { printf "%8d %02d:00-%02d:59\n", sum[i], i, i } }' >> $TMP + $SED -e 's/^[A-Z][a-z][a-z] *[0-9]* //' -e 's/:.* for / /' -e 's/ recips,.*$//' $TMPLOG | $AWK '{ val=int($1); sum[val]+=$ 2 } END { for (i=0; i<24; i++) { printf "%8d %02d:00-%02d:59\n", sum[i], i, i } }' >> $TMP else ---------------------------------------------------------------------- Comment By: Brad Knowles (shub) Date: 2005-09-22 16:17 Message: Logged In: YES user_id=18417 Okay, I took Mark's comments and incorporated them. Adrian Wells also pointed out a log file difference between Mailman 2.1.5 and 2.1.6 that caused the summary of the "smtp" log to be munged. I've now fixed these bugs, deleted the old file, and uploaded the new one (version 0.0.12). Thanks! ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-09-10 19:22 Message: Logged In: YES user_id=1123998 Oooops! I mistakenly thought I could add the mmdsr.patch as a downloadable file, but I can't so here it is. Watch out for wrapped lines ... --- mmdsr.orig 2005-09-06 20:37:53.000000000 -0700 +++ mmdsr 2005-09-10 18:33:14.532393572 -0700 @@ -132,6 +132,7 @@ MMDIR="/usr/local/mailman" TMPDIR="/tmp" +LOGDIR="/var/log/mailman" ############################################################################### # Maximum number of subdirectory entries to display in report @@ -234,9 +235,9 @@ $TOUCH $TMPLOG echo "Log file: $LOG" >> $TMP echo "==============================" >> $TMP - $GREP -si "^$DAY [0-9][0-9:]* $YEAR" logs/$LOG >> $TMPLOG + $GREP -si "^$DAY [0-9][0-9:]* $YEAR" $LOGDIR/$LOG >> $TMPLOG - if [ -f "logs/${LOG}" ] ; then + if [ -f "$LOGDIR/${LOG}" ] ; then if [ "${LOG}" = "post" ] ; then @@ -304,9 +305,9 @@ $TOUCH $TMPLOG echo "Log file: $LOG" >> $TMP echo "==============================" >> $TMP - $GREP -si "^$DAY [0-9][0-9:]* $YEAR" logs/$LOG >> $TMPLOG + $GREP -si "^$DAY [0-9][0-9:]* $YEAR" $LOGDIR/$LOG >> $TMPLOG - if [ -f "logs/${LOG}" ] ; then + if [ -f "$LOGDIR/${LOG}" ] ; then if [ "${LOG}" = "error" ] ; then @@ -453,4 +454,4 @@ $CAT $TMP fi -$RM $TMP +$RM -f $TMP $TMPLOG ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-09-10 19:16 Message: Logged In: YES user_id=1123998 I tried the script and other than the expected site specific changes, I found two issues which are both addressed by the patch in the mmdsr.patch file. 1) Mailman's log files are not necessarily in $var_prefix/logs/ - they can be in any directory. The patch adds a LOGDIR directory independant of MMDIR. 2) The $TMPLOG file is not removed at completion. The patch removes it. ---------------------------------------------------------------------- Comment By: Brad Knowles (shub) Date: 2005-09-06 07:06 Message: Logged In: YES user_id=18417 Okay, I've deleted the old version of the mmdsr script that was attached, and uploaded the latest version. This is what we're currently using to monitor the lists on python.org, and we have found it very useful. Any comments you may have will be appreciated. ---------------------------------------------------------------------- Comment By: Brad Knowles (shub) Date: 2005-02-22 12:10 Message: Logged In: YES user_id=18417 The UID variable in the current code was already replaced by MYUID, because I got complaints on other platforms. But UID wasn't available to me as a useful constant, so I had to use something else to obtain the value. The recommended patch from tgc99 does work, and I will be uploading a new version of the code soon. ---------------------------------------------------------------------- Comment By: adrianwi (adrianwi) Date: 2005-02-22 07:22 Message: Logged In: YES user_id=1175103 Use of variable named UID does work well with OS X (version 10.2.8). Apparently the variable UID is a constant already in use. When trying to the run the script without modification, I was receiving the following error message: UID: readonly variable This issue was resolved by changing the name of variable, UID, to something else, such as MMUID. Works fine with this change. As an aside (& for what it is worth), the UID grab command suggested by tgc99 on 2005-02-16 03:15 works on this system (OS X - version 10.2.8) ---------------------------------------------------------------------- Comment By: Tom G. Christensen (tgc99) Date: 2005-02-16 00:15 Message: Logged In: YES user_id=1159458 The current UID grab command doesn't work on Solaris (2.6 & 8 tested). I'd recommend this instead: ps -o user -p $$|tail -1 This is tested and works on RH 6.2, RH 7.3, RHEL 2.1, RHEL3, FC3, FreeBSD 4.9, Solaris 2.6, 8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1123383&group_id=103 From noreply at sourceforge.net Mon Nov 7 03:16:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Nov 2005 18:16:43 -0800 Subject: [ mailman-Bugs-1263239 ] Mailman on SSL sends passwords in plain text Message-ID: Bugs item #1263239, was opened at 2005-08-18 10:25 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1263239&group_id=103 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: None >Status: Closed Resolution: None Priority: 8 Submitted By: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: Mailman on SSL sends passwords in plain text Initial Comment: I have tried putting Mailman on a secure path of my server on an https url. It seemed to work approximately when adding the following directive in apache: RewriteCond %{HTTPS} !=on RewriteRule /mailman/(.*) https://www\.mysite\.com/mailman/$1 [R] However, I have sniffed the TCP/HTTP traffic during a list creation and I have seen that all the form is posted IN CLEAR. This is normal in fact as we send that to the http link first (see Bug Request #1263219). Therefore the whole test is sent in clear and only afterwards the client receives back the document move to https from apache to redirect to the proper page. I think that this could be solved if all links of the mailman binaries (admin, create and so forth) are taking dynamically the link specified in the mm_cfg.py, in the DEFAULT_URL_HOST tag. However maybe there is another clean way of putting that on a secure url. If so I would be interested in how to do that because I didn't find anything about that subject appart people doing all like I did. Thanks, Daniel ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-11-06 18:16 Message: Logged In: YES user_id=1123998 I am closing this because it seems to be a misconfiguration. If you make DEFAULT_URL_PATTERN = 'https://%s/mailman/' or similar (with https) in mm_cfg.py, the create page link from the admin overview will have https as will the action= attribute of the form element on the create page. As you note, you must run fix_url.py to fix list specific URLs after making this change, but generic urls are changed without further action. Also note that DEFAULT_URL_HOST should be just the fully qualified domain name. The rest of the URL comes from substituting the host name in DEFAULT_URL_PATTERN. ---------------------------------------------------------------------- Comment By: Daniel (doolyo) Date: 2005-08-18 11:09 Message: Logged In: YES user_id=1320890 P.S.: I have seen that we can use fix_url.py to fix the URL for a specific list. However, it does not seem to fix the links of /mailman/create and the others and thus does not solve the problem, as I want to have the SSL on that page. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1263239&group_id=103 From noreply at sourceforge.net Mon Nov 7 03:33:22 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Nov 2005 18:33:22 -0800 Subject: [ mailman-Bugs-1263219 ] Link of the 'admin' page not updated if config change Message-ID: Bugs item #1263219, was opened at 2005-08-18 09:57 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1263219&group_id=103 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: None >Status: Closed Resolution: None Priority: 5 Submitted By: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: Link of the 'admin' page not updated if config change Initial Comment: If I change the mailman url on the server, the link displayed on the admin page that shows the 'mailing list overview page' is not updated in consequence. I have put the followings in mm_cfg.py: DEFAULT_URL_HOST = 'https://www.mysite.com/mailman' (secure connection), and we can see on the admin page that the link is on the http:// page and not https://. It should also be the same for the other pages. BTW it would be good if we could also change the pages ourselves. Thanks. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-11-06 18:33 Message: Logged In: YES user_id=1123998 I am closing this because it seems to be a misconfiguration. If you make DEFAULT_URL_PATTERN = 'https://%s/mailman/' or similar (with https) in mm_cfg.py, the listinfo overview link from the admin overview will have https as will the create link. DEFAULT_URL_HOST should be just the fully qualified domain name, not a URL. The rest of the URL comes from substituting the host name in DEFAULT_URL_PATTERN. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1263219&group_id=103 From noreply at sourceforge.net Mon Nov 7 03:36:21 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 06 Nov 2005 18:36:21 -0800 Subject: [ mailman-Bugs-1263219 ] Link of the 'admin' page not updated if config change Message-ID: Bugs item #1263219, was opened at 2005-08-18 09:57 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1263219&group_id=103 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: None Status: Closed Resolution: None Priority: 5 Submitted By: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: Link of the 'admin' page not updated if config change Initial Comment: If I change the mailman url on the server, the link displayed on the admin page that shows the 'mailing list overview page' is not updated in consequence. I have put the followings in mm_cfg.py: DEFAULT_URL_HOST = 'https://www.mysite.com/mailman' (secure connection), and we can see on the admin page that the link is on the http:// page and not https://. It should also be the same for the other pages. BTW it would be good if we could also change the pages ourselves. Thanks. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-11-06 18:36 Message: Logged In: YES user_id=1123998 And yes, it would be nice if these pages were built from editable templates, but that's an RFE, not a bug. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-06 18:33 Message: Logged In: YES user_id=1123998 I am closing this because it seems to be a misconfiguration. If you make DEFAULT_URL_PATTERN = 'https://%s/mailman/' or similar (with https) in mm_cfg.py, the listinfo overview link from the admin overview will have https as will the create link. DEFAULT_URL_HOST should be just the fully qualified domain name, not a URL. The rest of the URL comes from substituting the host name in DEFAULT_URL_PATTERN. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1263219&group_id=103 From noreply at sourceforge.net Wed Nov 9 02:14:26 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 17:14:26 -0800 Subject: [ mailman-Bugs-1268939 ] host_name tag doesn't allow IP addresses Message-ID: Bugs item #1268939, was opened at 2005-08-24 12:11 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1268939&group_id=103 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: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: host_name tag doesn't allow IP addresses Initial Comment: Hello. I have realised that we cannot put an IP address in the 'host_name' tag. Normally, we can send an e-mail from a client to a server that doesn't have a domain name by just putting it's IP address into square brackets like this: john@[142.56.2.72] This works, especially if you have put the same IP address on the destination server in your /etc/mail/local- host-names file on one line (for Sendmail): [142.56.2.72] Now the problem is that if we specify the IP address into square brackets in the 'host_name' tag, then the resolved hostname is returned in the e-mail address instead of this square brackets IP address. I have tried several backslashes like '', [], "", %5B and % 5D but nothing does. Square brackets are still correct to the standard, so I think that this is a bug. Regards, Daniel ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-11-08 17:14 Message: Logged In: YES user_id=1123998 Can you be more specific? I have tested both Mailman 2.1.5 and 2.1.6 and they accept a host_name of the form [142.56.2.72] on the General Options page with no problem. Is your issue that you can't get General Options to accept a numeric IP in square brackets, or that it is accepted, but it gets 'changed' somewhere else. Please clarify, and if the latter, please be specific about where you observe the 'change'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1268939&group_id=103 From noreply at sourceforge.net Wed Nov 9 02:21:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 17:21:56 -0800 Subject: [ mailman-Feature Requests-1269025 ] unsubscribe removal confirmation should be optional Message-ID: Feature Requests item #1269025, was opened at 2005-08-24 12:55 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1269025&group_id=103 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: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: unsubscribe removal confirmation should be optional Initial Comment: We should be able to choose if we want the members that unsubscribe by e-mail to receive a 'removal confirmation' e-mail. I need the user to not receive this notice and just remove him without him knowing it. However, we should still be able to sent him the good_bye message when he left if we want it, like it's the case currently. The removal notice is not really necessary if people receive an e-mail telling that they have been removed. They can submit again if they want and report the abuse. This option should just be an added tag that would be valid for the whole list. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-11-08 17:21 Message: Logged In: YES user_id=1123998 I'm moving this to "Feature Requests" as it is not a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1269025&group_id=103 From noreply at sourceforge.net Wed Nov 9 02:28:43 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 17:28:43 -0800 Subject: [ mailman-Feature Requests-1269067 ] e-mail command confirmations should be optional Message-ID: Feature Requests item #1269067, was opened at 2005-08-24 13:09 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1269067&group_id=103 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: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: e-mail command confirmations should be optional Initial Comment: When we send an e-mail to change the member's options with a command (e.g. to subscribe/unsubscribe members), the confirmation of the commands should be optionnal. This is useful particularly if we do a php script that sends the commands automatically from a post field. Then the member doesn't need to see all those e-mail commands. This should be an optional command that would disable these confirmations for the whole list and all commands. www.Sympa.org mailing list does this very well. Thank you. Daniel ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-11-08 17:28 Message: Logged In: YES user_id=1123998 I'm moving this to "Feature Requests" as it is not a bug. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-03 17:24 Message: Logged In: YES user_id=1123998 In general, I think this is a bad idea because it allows anyone to subscribe anyone else to a list by spoofing their email address in an email command. If you really want to open up subscribing without confirmation, that feature is already available. Put ALLOW_OPEN_SUBSCRIBE = Yes in mm_cfg.py and lists will have a None option for subscribe_policy which will allow subscribe without confirmation. ---------------------------------------------------------------------- Comment By: moshe weitzman (weitzman) Date: 2005-11-03 06:05 Message: Logged In: YES user_id=199362 I too need this. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1269067&group_id=103 From noreply at sourceforge.net Wed Nov 9 03:49:15 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 08 Nov 2005 18:49:15 -0800 Subject: [ mailman-Bugs-1263213 ] checkbox "Send list created" not saved if failure Message-ID: Bugs item #1263213, was opened at 2005-08-18 09:50 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1263213&group_id=103 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: None >Status: Closed Resolution: None Priority: 5 Submitted By: Daniel (doolyo) >Assigned to: Mark Sapiro (msapiro) Summary: checkbox "Send list created" not saved if failure Initial Comment: On the list creation page (/mailman/create), if we check the "Send list created e-mail to list owner" button to 'yes' and that we put a wrong password by submitting the form, the checkbox will come back to 'no'. This is not the case with the other checkboxes or the text, everything else comes back to the previously chosen values. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-11-08 18:49 Message: Logged In: YES user_id=1123998 The attached patch fixes the bug including correctly initializing the button from DEFAULT_DEFAULT_MEMBER_MODERATION and remembering the prior choice across errors. There is still an issue in that language selections are not remembered across errors. ---------------------------------------------------------------------- Comment By: Daniel (doolyo) Date: 2005-08-18 11:49 Message: Logged In: YES user_id=1320890 Oops, sorry. It is not the correct checkbox. It is the other, called 'Should new members be quarantined before they are allowed to post unmoderated to this list?'. The rest is true for the fact that it looses it's 'yes' value. Thanks, Daniel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1263213&group_id=103 From noreply at sourceforge.net Wed Nov 9 10:34:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 01:34:12 -0800 Subject: [ mailman-Bugs-1268939 ] host_name tag doesn't allow IP addresses Message-ID: Bugs item #1268939, was opened at 2005-08-24 19:11 Message generated for change (Comment added) made by doolyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1268939&group_id=103 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: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: host_name tag doesn't allow IP addresses Initial Comment: Hello. I have realised that we cannot put an IP address in the 'host_name' tag. Normally, we can send an e-mail from a client to a server that doesn't have a domain name by just putting it's IP address into square brackets like this: john@[142.56.2.72] This works, especially if you have put the same IP address on the destination server in your /etc/mail/local- host-names file on one line (for Sendmail): [142.56.2.72] Now the problem is that if we specify the IP address into square brackets in the 'host_name' tag, then the resolved hostname is returned in the e-mail address instead of this square brackets IP address. I have tried several backslashes like '', [], "", %5B and % 5D but nothing does. Square brackets are still correct to the standard, so I think that this is a bug. Regards, Daniel ---------------------------------------------------------------------- >Comment By: Daniel (doolyo) Date: 2005-11-09 09:34 Message: Logged In: YES user_id=1320890 The 'host_name' tag I am speaking about is in the /etc/mailman/*.cfg file (or /var/lib/mailman/data/*.cfg). I can make the host_name accept the squared brackets IP address without any problem. It stays there and it is properly placed in the file, it is not changed. However, when I send an e-mail to the list itself, then the e- mail is indicated to come from 'myhost.mydomain.com' instead of keeping '[142.56.2.72]'. That is my problem, because I would like people to be able to answer to this IP address instead of the host name, as this host name is not yet active due to the fact that I am configuring Mailman and testing it. Once it passes my tests, then the domain will be active, but I need this 'from' header containing this exact same '[142.56.2.72]' string than 'host_name' for the system to receive back the e-mails. Kind regards, Daniel ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-09 01:14 Message: Logged In: YES user_id=1123998 Can you be more specific? I have tested both Mailman 2.1.5 and 2.1.6 and they accept a host_name of the form [142.56.2.72] on the General Options page with no problem. Is your issue that you can't get General Options to accept a numeric IP in square brackets, or that it is accepted, but it gets 'changed' somewhere else. Please clarify, and if the latter, please be specific about where you observe the 'change'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1268939&group_id=103 From noreply at sourceforge.net Wed Nov 9 10:39:14 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 01:39:14 -0800 Subject: [ mailman-Feature Requests-1269025 ] unsubscribe removal confirmation should be optional Message-ID: Feature Requests item #1269025, was opened at 2005-08-24 19:55 Message generated for change (Comment added) made by doolyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1269025&group_id=103 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: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: unsubscribe removal confirmation should be optional Initial Comment: We should be able to choose if we want the members that unsubscribe by e-mail to receive a 'removal confirmation' e-mail. I need the user to not receive this notice and just remove him without him knowing it. However, we should still be able to sent him the good_bye message when he left if we want it, like it's the case currently. The removal notice is not really necessary if people receive an e-mail telling that they have been removed. They can submit again if they want and report the abuse. This option should just be an added tag that would be valid for the whole list. ---------------------------------------------------------------------- >Comment By: Daniel (doolyo) Date: 2005-11-09 09:39 Message: Logged In: YES user_id=1320890 Ok, thanks. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-09 01:21 Message: Logged In: YES user_id=1123998 I'm moving this to "Feature Requests" as it is not a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1269025&group_id=103 From noreply at sourceforge.net Wed Nov 9 10:51:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 01:51:00 -0800 Subject: [ mailman-Feature Requests-1269067 ] e-mail command confirmations should be optional Message-ID: Feature Requests item #1269067, was opened at 2005-08-24 20:09 Message generated for change (Comment added) made by doolyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1269067&group_id=103 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: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: e-mail command confirmations should be optional Initial Comment: When we send an e-mail to change the member's options with a command (e.g. to subscribe/unsubscribe members), the confirmation of the commands should be optionnal. This is useful particularly if we do a php script that sends the commands automatically from a post field. Then the member doesn't need to see all those e-mail commands. This should be an optional command that would disable these confirmations for the whole list and all commands. www.Sympa.org mailing list does this very well. Thank you. Daniel ---------------------------------------------------------------------- >Comment By: Daniel (doolyo) Date: 2005-11-09 09:51 Message: Logged In: YES user_id=1320890 Ok, thank you for that information, it works now. I understand your concern, and allowing free subscriptions from only certain hosts would be an idea of new feature request. It's my case where it's always the server that send an e-mail to mailman to subscribe people. It is a bit more difficult for people to use my script by spoofing it, and I can prevent more than 3 e-mails per day per IP address if really needed. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-09 01:28 Message: Logged In: YES user_id=1123998 I'm moving this to "Feature Requests" as it is not a bug. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-04 01:24 Message: Logged In: YES user_id=1123998 In general, I think this is a bad idea because it allows anyone to subscribe anyone else to a list by spoofing their email address in an email command. If you really want to open up subscribing without confirmation, that feature is already available. Put ALLOW_OPEN_SUBSCRIBE = Yes in mm_cfg.py and lists will have a None option for subscribe_policy which will allow subscribe without confirmation. ---------------------------------------------------------------------- Comment By: moshe weitzman (weitzman) Date: 2005-11-03 14:05 Message: Logged In: YES user_id=199362 I too need this. Thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1269067&group_id=103 From noreply at sourceforge.net Wed Nov 9 10:53:30 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 01:53:30 -0800 Subject: [ mailman-Bugs-1263213 ] checkbox "Send list created" not saved if failure Message-ID: Bugs item #1263213, was opened at 2005-08-18 16:50 Message generated for change (Comment added) made by doolyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1263213&group_id=103 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: None Status: Closed Resolution: None Priority: 5 Submitted By: Daniel (doolyo) Assigned to: Mark Sapiro (msapiro) Summary: checkbox "Send list created" not saved if failure Initial Comment: On the list creation page (/mailman/create), if we check the "Send list created e-mail to list owner" button to 'yes' and that we put a wrong password by submitting the form, the checkbox will come back to 'no'. This is not the case with the other checkboxes or the text, everything else comes back to the previously chosen values. ---------------------------------------------------------------------- >Comment By: Daniel (doolyo) Date: 2005-11-09 09:53 Message: Logged In: YES user_id=1320890 Thanks for that, msapiro. Regards, Daniel ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-09 02:49 Message: Logged In: YES user_id=1123998 The attached patch fixes the bug including correctly initializing the button from DEFAULT_DEFAULT_MEMBER_MODERATION and remembering the prior choice across errors. There is still an issue in that language selections are not remembered across errors. ---------------------------------------------------------------------- Comment By: Daniel (doolyo) Date: 2005-08-18 18:49 Message: Logged In: YES user_id=1320890 Oops, sorry. It is not the correct checkbox. It is the other, called 'Should new members be quarantined before they are allowed to post unmoderated to this list?'. The rest is true for the fact that it looses it's 'yes' value. Thanks, Daniel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1263213&group_id=103 From noreply at sourceforge.net Wed Nov 9 17:07:27 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 08:07:27 -0800 Subject: [ mailman-Patches-1352333 ] New Unified XMLRPC Patch Message-ID: Patches item #1352333, was opened at 2005-11-09 09:07 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=1352333&group_id=103 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.2 / 3.0 Status: Open Resolution: None Priority: 5 Submitted By: Joshua Ginsberg (jaginsberg) Assigned to: Nobody/Anonymous (nobody) Summary: New Unified XMLRPC Patch Initial Comment: This is the unified XMLRPC patch coauthored by myself and Joseph Tate. It supercedes the patch in 1244799. -jag ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1352333&group_id=103 From noreply at sourceforge.net Wed Nov 9 17:08:12 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 09 Nov 2005 08:08:12 -0800 Subject: [ mailman-Patches-1244799 ] XML-RPC interface to Mailman Message-ID: Patches item #1244799, was opened at 2005-07-25 15:29 Message generated for change (Comment added) made by jaginsberg You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1244799&group_id=103 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 UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Joseph Tate (jtate) Assigned to: Nobody/Anonymous (nobody) Summary: XML-RPC interface to Mailman Initial Comment: This patch adds an XML-RPC public interface to Mailman 2.1.6. The functionality is very basic but includes interfaces for adding and deleting lists, setting list settings, and adding/removing/listing subscribers. There are also some changes made to a few Cgi and command line interfaces to break functionality away from output generation so that they could be more easily reused. ---------------------------------------------------------------------- Comment By: Joshua Ginsberg (jaginsberg) Date: 2005-11-09 09:08 Message: Logged In: YES user_id=638741 This patch has been superceded by the unified patch coauthored by jtate and myself. See 1352333 for the code. -jag ---------------------------------------------------------------------- Comment By: Joseph Tate (jtate) Date: 2005-08-03 09:58 Message: Logged In: YES user_id=55276 Fix a bug in the Cgi/create.py script. Complete patch attached. ---------------------------------------------------------------------- Comment By: Joseph Tate (jtate) Date: 2005-08-01 08:10 Message: Logged In: YES user_id=55276 I've updated the patch. There were some problems in the way that I was doing some things. This version of the patch will remain static for the forseeable future. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1244799&group_id=103 From noreply at sourceforge.net Sat Nov 12 19:58:46 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 10:58:46 -0800 Subject: [ mailman-Bugs-1355389 ] Support sensible downgrades Message-ID: Bugs item #1355389, was opened at 2005-11-12 19:58 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=1355389&group_id=103 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: configuring/installing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Schoinobates Volans (schoinobates) Assigned to: Nobody/Anonymous (nobody) Summary: Support sensible downgrades Initial Comment: bin/upgrade currently aborts on _all_ downgrades. However, AFAIK, there are some version ranges that don't change the database format and then downgrading within this range would be safe. Please make bin/update more intelligent as to accept safe downgrades. Thanks. (Forwarded from http://bugs.debian.org/157800) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1355389&group_id=103 From noreply at sourceforge.net Sun Nov 13 01:01:32 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 16:01:32 -0800 Subject: [ mailman-Patches-1287921 ] post log entries show envelope sender, not From: Message-ID: Patches item #1287921, was opened at 2005-09-11 11:00 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287921&group_id=103 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: Closed Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) >Assigned to: Mark Sapiro (msapiro) Summary: post log entries show envelope sender, not From: Initial Comment: The interpolation dictionary used with the SMTPDirect.py log messages includes 'sender' which is obtained with the Message.get_sender() method. If mm_cfg.USE_ENVELOPE_SENDER is Yes, this method returns the envelope sender which, since this is an outgoing message, is always the listname-bounces address. Since 'listname' is already in the dictionary, this is redundant. It would be more useful, at least for lists which aren't anonymous, to override this behavior and get the sender with get_sender(use_envelope=0) which would return the From: address. The patch makes this change. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-11-12 16:01 Message: Logged In: YES user_id=1123998 This has been fixed differently from the patch that was here. The patch would always use the From:, but the fix correctly calls msg.get_sender() without forcing use_envelope=0; it just does it earlier. The fix is in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287921&group_id=103 From noreply at sourceforge.net Sun Nov 13 03:46:10 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 18:46:10 -0800 Subject: [ mailman-Patches-1318883 ] Line following Approved: line in body of post is stripped Message-ID: Patches item #1318883, was opened at 2005-10-08 14:12 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1318883&group_id=103 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: Closed Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) >Assigned to: Mark Sapiro (msapiro) Summary: Line following Approved: line in body of post is stripped Initial Comment: If a post contains an [Aa]pproved?: line as the first non-blank line of the first text/plain part (and doesn't contain an Approved?: header), the line itself is deleted, but so is the first of the remaining lines. If this first remaining line is a blank line which preceeded the Approved: line, no harm is done, but if there are no blank lines preceeding the Approved: line, the line following the Approved: line which may be non-blank is stripped. This occurs because after the Approved: line is removed, the remaining lines are re-joined beginning with line 1 and not line 0. The patch to Mailman/Handlers/Approve.py corrects this. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-11-12 18:46 Message: Logged In: YES user_id=1123998 Patch has been commited in CVS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1318883&group_id=103 From noreply at sourceforge.net Sun Nov 13 03:50:45 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 18:50:45 -0800 Subject: [ mailman-Bugs-1355707 ] Approve: header not removed from post Message-ID: Bugs item #1355707, was opened at 2005-11-12 18:50 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=1355707&group_id=103 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: Open Resolution: None Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Mark Sapiro (msapiro) Summary: Approve: header not removed from post Initial Comment: Cleanse.py removes Approved: header, but not Approve: even though Approve.py accepts Approve: Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1355707&group_id=103 From noreply at sourceforge.net Sun Nov 13 03:51:42 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 12 Nov 2005 18:51:42 -0800 Subject: [ mailman-Bugs-1355707 ] Approve: header not removed from post Message-ID: Bugs item #1355707, was opened at 2005-11-12 18:50 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1355707&group_id=103 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: None Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Mark Sapiro (msapiro) Summary: Approve: header not removed from post Initial Comment: Cleanse.py removes Approved: header, but not Approve: even though Approve.py accepts Approve: Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1355707&group_id=103 From noreply at sourceforge.net Mon Nov 14 00:59:49 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 13 Nov 2005 15:59:49 -0800 Subject: [ mailman-Bugs-1268939 ] host_name tag doesn't allow IP addresses Message-ID: Bugs item #1268939, was opened at 2005-08-24 12:11 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1268939&group_id=103 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: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: host_name tag doesn't allow IP addresses Initial Comment: Hello. I have realised that we cannot put an IP address in the 'host_name' tag. Normally, we can send an e-mail from a client to a server that doesn't have a domain name by just putting it's IP address into square brackets like this: john@[142.56.2.72] This works, especially if you have put the same IP address on the destination server in your /etc/mail/local- host-names file on one line (for Sendmail): [142.56.2.72] Now the problem is that if we specify the IP address into square brackets in the 'host_name' tag, then the resolved hostname is returned in the e-mail address instead of this square brackets IP address. I have tried several backslashes like '', [], "", %5B and % 5D but nothing does. Square brackets are still correct to the standard, so I think that this is a bug. Regards, Daniel ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-11-13 15:59 Message: Logged In: YES user_id=1123998 What version of mailman is this? Installed from source or from rpm or other package? In the standard installation the only .cfg file is data/sitelist.cfg. This is provided as an aid to configuring the site list (mailman list) because the normal site defaults for a new list are probably not appropriate for the site list. This file, sitelist.cfg, is intended to be used as input to bin/config_list to actually configure the list. Mailman itself in operation doesn't get anything from any *.cfg file. Actual list configurations are in lists/*/config.pck. So, are you just putting something in some *.cfg file and that's it, or do you or some other custom process in your installation actually run bin/config_list or equivalent to transfer that information the the actual list configuration? If in fact, you have updated the list configuration such that the value of host_name visible on the list's General Options in the web admin interface or visible in the output from 'bin/config_list -o' or in the output from 'bin/dumpdb lists/list_name/config.pck' is the bracketed numeric IP address, and you still have the problem of it being changed, then I think it must be your outgoing MTA that is changing it, not Mailman. As far as I can tell, Mailman always uses the list's host_name attribute as the domain for email addresses. The only exception is for the site list in some cases where the email domain is obtained from the VIRTUAL_HOSTS dictionary which is built by add_virtualhost() directives in Defaults.py/mm_cfg.py. If you have not actually changed the list's host_name attribute because you've only changed some .cfg file and nothing more, then you need to actually update the list. ---------------------------------------------------------------------- Comment By: Daniel (doolyo) Date: 2005-11-09 01:34 Message: Logged In: YES user_id=1320890 The 'host_name' tag I am speaking about is in the /etc/mailman/*.cfg file (or /var/lib/mailman/data/*.cfg). I can make the host_name accept the squared brackets IP address without any problem. It stays there and it is properly placed in the file, it is not changed. However, when I send an e-mail to the list itself, then the e- mail is indicated to come from 'myhost.mydomain.com' instead of keeping '[142.56.2.72]'. That is my problem, because I would like people to be able to answer to this IP address instead of the host name, as this host name is not yet active due to the fact that I am configuring Mailman and testing it. Once it passes my tests, then the domain will be active, but I need this 'from' header containing this exact same '[142.56.2.72]' string than 'host_name' for the system to receive back the e-mails. Kind regards, Daniel ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-08 17:14 Message: Logged In: YES user_id=1123998 Can you be more specific? I have tested both Mailman 2.1.5 and 2.1.6 and they accept a host_name of the form [142.56.2.72] on the General Options page with no problem. Is your issue that you can't get General Options to accept a numeric IP in square brackets, or that it is accepted, but it gets 'changed' somewhere else. Please clarify, and if the latter, please be specific about where you observe the 'change'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1268939&group_id=103 From noreply at sourceforge.net Mon Nov 14 09:10:19 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 00:10:19 -0800 Subject: [ mailman-Bugs-1356361 ] RFE - Check for Welcome Responses Message-ID: Bugs item #1356361, was opened at 2005-11-14 00:10 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=1356361&group_id=103 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: None Status: Open Resolution: None Priority: 5 Submitted By: Michael A. Peters (funkyres) Assigned to: Nobody/Anonymous (nobody) Summary: RFE - Check for Welcome Responses Initial Comment: Mailman should filter out replies to the Welcome message. This happened on the Fedora User list - a new subscriber accidentally sent the welcome message - including their password - to the list. It shouldn't be *too* difficult to check for that and filter those kind of blunders, so that password are not disclosed to everyone. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1356361&group_id=103 From noreply at sourceforge.net Mon Nov 14 21:19:13 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 14 Nov 2005 12:19:13 -0800 Subject: [ mailman-Bugs-1268939 ] host_name tag doesn't allow IP addresses Message-ID: Bugs item #1268939, was opened at 2005-08-24 19:11 Message generated for change (Comment added) made by doolyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1268939&group_id=103 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: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: host_name tag doesn't allow IP addresses Initial Comment: Hello. I have realised that we cannot put an IP address in the 'host_name' tag. Normally, we can send an e-mail from a client to a server that doesn't have a domain name by just putting it's IP address into square brackets like this: john@[142.56.2.72] This works, especially if you have put the same IP address on the destination server in your /etc/mail/local- host-names file on one line (for Sendmail): [142.56.2.72] Now the problem is that if we specify the IP address into square brackets in the 'host_name' tag, then the resolved hostname is returned in the e-mail address instead of this square brackets IP address. I have tried several backslashes like '', [], "", %5B and % 5D but nothing does. Square brackets are still correct to the standard, so I think that this is a bug. Regards, Daniel ---------------------------------------------------------------------- >Comment By: Daniel (doolyo) Date: 2005-11-14 20:19 Message: Logged In: YES user_id=1320890 The version of Mailman is mailman-2.1.5-33. It is installed from an RPM for RHEL4 (centOS4). The configuration file is the correct one and is properly done through the web interface. I don't think that it is the MTA which causes problems because it works well when I use it directly like this: 'mail john@[142.56.2.72]'. Therefore I still think that this could be a bug. Could someone try that on another setup ? Regards, Daniel ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-13 23:59 Message: Logged In: YES user_id=1123998 What version of mailman is this? Installed from source or from rpm or other package? In the standard installation the only .cfg file is data/sitelist.cfg. This is provided as an aid to configuring the site list (mailman list) because the normal site defaults for a new list are probably not appropriate for the site list. This file, sitelist.cfg, is intended to be used as input to bin/config_list to actually configure the list. Mailman itself in operation doesn't get anything from any *.cfg file. Actual list configurations are in lists/*/config.pck. So, are you just putting something in some *.cfg file and that's it, or do you or some other custom process in your installation actually run bin/config_list or equivalent to transfer that information the the actual list configuration? If in fact, you have updated the list configuration such that the value of host_name visible on the list's General Options in the web admin interface or visible in the output from 'bin/config_list -o' or in the output from 'bin/dumpdb lists/list_name/config.pck' is the bracketed numeric IP address, and you still have the problem of it being changed, then I think it must be your outgoing MTA that is changing it, not Mailman. As far as I can tell, Mailman always uses the list's host_name attribute as the domain for email addresses. The only exception is for the site list in some cases where the email domain is obtained from the VIRTUAL_HOSTS dictionary which is built by add_virtualhost() directives in Defaults.py/mm_cfg.py. If you have not actually changed the list's host_name attribute because you've only changed some .cfg file and nothing more, then you need to actually update the list. ---------------------------------------------------------------------- Comment By: Daniel (doolyo) Date: 2005-11-09 09:34 Message: Logged In: YES user_id=1320890 The 'host_name' tag I am speaking about is in the /etc/mailman/*.cfg file (or /var/lib/mailman/data/*.cfg). I can make the host_name accept the squared brackets IP address without any problem. It stays there and it is properly placed in the file, it is not changed. However, when I send an e-mail to the list itself, then the e- mail is indicated to come from 'myhost.mydomain.com' instead of keeping '[142.56.2.72]'. That is my problem, because I would like people to be able to answer to this IP address instead of the host name, as this host name is not yet active due to the fact that I am configuring Mailman and testing it. Once it passes my tests, then the domain will be active, but I need this 'from' header containing this exact same '[142.56.2.72]' string than 'host_name' for the system to receive back the e-mails. Kind regards, Daniel ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-09 01:14 Message: Logged In: YES user_id=1123998 Can you be more specific? I have tested both Mailman 2.1.5 and 2.1.6 and they accept a host_name of the form [142.56.2.72] on the General Options page with no problem. Is your issue that you can't get General Options to accept a numeric IP in square brackets, or that it is accepted, but it gets 'changed' somewhere else. Please clarify, and if the latter, please be specific about where you observe the 'change'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1268939&group_id=103 From noreply at sourceforge.net Tue Nov 15 09:24:53 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Nov 2005 00:24:53 -0800 Subject: [ mailman-Bugs-1268939 ] host_name tag doesn't allow IP addresses Message-ID: Bugs item #1268939, was opened at 2005-08-24 19:11 Message generated for change (Comment added) made by doolyo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1268939&group_id=103 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: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: host_name tag doesn't allow IP addresses Initial Comment: Hello. I have realised that we cannot put an IP address in the 'host_name' tag. Normally, we can send an e-mail from a client to a server that doesn't have a domain name by just putting it's IP address into square brackets like this: john@[142.56.2.72] This works, especially if you have put the same IP address on the destination server in your /etc/mail/local- host-names file on one line (for Sendmail): [142.56.2.72] Now the problem is that if we specify the IP address into square brackets in the 'host_name' tag, then the resolved hostname is returned in the e-mail address instead of this square brackets IP address. I have tried several backslashes like '', [], "", %5B and % 5D but nothing does. Square brackets are still correct to the standard, so I think that this is a bug. Regards, Daniel ---------------------------------------------------------------------- >Comment By: Daniel (doolyo) Date: 2005-11-15 08:24 Message: Logged In: YES user_id=1320890 Hello, msapiro. Thanks for that test. I don't know then what happened at that time on my box, but when I was sending something to a box configured like that with this address in brackets it was not received or processed. Now that you successfully tested it ony our side then my assumption that there was a problem by interpreting the brackets is gone. Maybe there was still a problem with the MTA for incoming mails but it's difficult to say. I don't have anymore that setup now as it's several months I have tested this, so I cannot reproduce this currently. Therefore I think that you can close this report. Thanks for your try. Best regards, Daniel ---------------------------------------------------------------------- Comment By: Daniel (doolyo) Date: 2005-11-14 20:19 Message: Logged In: YES user_id=1320890 The version of Mailman is mailman-2.1.5-33. It is installed from an RPM for RHEL4 (centOS4). The configuration file is the correct one and is properly done through the web interface. I don't think that it is the MTA which causes problems because it works well when I use it directly like this: 'mail john@[142.56.2.72]'. Therefore I still think that this could be a bug. Could someone try that on another setup ? Regards, Daniel ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-13 23:59 Message: Logged In: YES user_id=1123998 What version of mailman is this? Installed from source or from rpm or other package? In the standard installation the only .cfg file is data/sitelist.cfg. This is provided as an aid to configuring the site list (mailman list) because the normal site defaults for a new list are probably not appropriate for the site list. This file, sitelist.cfg, is intended to be used as input to bin/config_list to actually configure the list. Mailman itself in operation doesn't get anything from any *.cfg file. Actual list configurations are in lists/*/config.pck. So, are you just putting something in some *.cfg file and that's it, or do you or some other custom process in your installation actually run bin/config_list or equivalent to transfer that information the the actual list configuration? If in fact, you have updated the list configuration such that the value of host_name visible on the list's General Options in the web admin interface or visible in the output from 'bin/config_list -o' or in the output from 'bin/dumpdb lists/list_name/config.pck' is the bracketed numeric IP address, and you still have the problem of it being changed, then I think it must be your outgoing MTA that is changing it, not Mailman. As far as I can tell, Mailman always uses the list's host_name attribute as the domain for email addresses. The only exception is for the site list in some cases where the email domain is obtained from the VIRTUAL_HOSTS dictionary which is built by add_virtualhost() directives in Defaults.py/mm_cfg.py. If you have not actually changed the list's host_name attribute because you've only changed some .cfg file and nothing more, then you need to actually update the list. ---------------------------------------------------------------------- Comment By: Daniel (doolyo) Date: 2005-11-09 09:34 Message: Logged In: YES user_id=1320890 The 'host_name' tag I am speaking about is in the /etc/mailman/*.cfg file (or /var/lib/mailman/data/*.cfg). I can make the host_name accept the squared brackets IP address without any problem. It stays there and it is properly placed in the file, it is not changed. However, when I send an e-mail to the list itself, then the e- mail is indicated to come from 'myhost.mydomain.com' instead of keeping '[142.56.2.72]'. That is my problem, because I would like people to be able to answer to this IP address instead of the host name, as this host name is not yet active due to the fact that I am configuring Mailman and testing it. Once it passes my tests, then the domain will be active, but I need this 'from' header containing this exact same '[142.56.2.72]' string than 'host_name' for the system to receive back the e-mails. Kind regards, Daniel ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-09 01:14 Message: Logged In: YES user_id=1123998 Can you be more specific? I have tested both Mailman 2.1.5 and 2.1.6 and they accept a host_name of the form [142.56.2.72] on the General Options page with no problem. Is your issue that you can't get General Options to accept a numeric IP in square brackets, or that it is accepted, but it gets 'changed' somewhere else. Please clarify, and if the latter, please be specific about where you observe the 'change'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1268939&group_id=103 From noreply at sourceforge.net Wed Nov 16 05:35:23 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 15 Nov 2005 20:35:23 -0800 Subject: [ mailman-Bugs-1268939 ] host_name tag doesn't allow IP addresses Message-ID: Bugs item #1268939, was opened at 2005-08-24 12:11 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1268939&group_id=103 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: None Priority: 5 Submitted By: Daniel (doolyo) Assigned to: Nobody/Anonymous (nobody) Summary: host_name tag doesn't allow IP addresses Initial Comment: Hello. I have realised that we cannot put an IP address in the 'host_name' tag. Normally, we can send an e-mail from a client to a server that doesn't have a domain name by just putting it's IP address into square brackets like this: john@[142.56.2.72] This works, especially if you have put the same IP address on the destination server in your /etc/mail/local- host-names file on one line (for Sendmail): [142.56.2.72] Now the problem is that if we specify the IP address into square brackets in the 'host_name' tag, then the resolved hostname is returned in the e-mail address instead of this square brackets IP address. I have tried several backslashes like '', [], "", %5B and % 5D but nothing does. Square brackets are still correct to the standard, so I think that this is a bug. Regards, Daniel ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-11-15 20:35 Message: Logged In: YES user_id=1123998 Testing confirms that Mailman will accept and us a literal IP address as host_name for a list. This report is closed. ---------------------------------------------------------------------- Comment By: Daniel (doolyo) Date: 2005-11-15 00:24 Message: Logged In: YES user_id=1320890 Hello, msapiro. Thanks for that test. I don't know then what happened at that time on my box, but when I was sending something to a box configured like that with this address in brackets it was not received or processed. Now that you successfully tested it ony our side then my assumption that there was a problem by interpreting the brackets is gone. Maybe there was still a problem with the MTA for incoming mails but it's difficult to say. I don't have anymore that setup now as it's several months I have tested this, so I cannot reproduce this currently. Therefore I think that you can close this report. Thanks for your try. Best regards, Daniel ---------------------------------------------------------------------- Comment By: Daniel (doolyo) Date: 2005-11-14 12:19 Message: Logged In: YES user_id=1320890 The version of Mailman is mailman-2.1.5-33. It is installed from an RPM for RHEL4 (centOS4). The configuration file is the correct one and is properly done through the web interface. I don't think that it is the MTA which causes problems because it works well when I use it directly like this: 'mail john@[142.56.2.72]'. Therefore I still think that this could be a bug. Could someone try that on another setup ? Regards, Daniel ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-13 15:59 Message: Logged In: YES user_id=1123998 What version of mailman is this? Installed from source or from rpm or other package? In the standard installation the only .cfg file is data/sitelist.cfg. This is provided as an aid to configuring the site list (mailman list) because the normal site defaults for a new list are probably not appropriate for the site list. This file, sitelist.cfg, is intended to be used as input to bin/config_list to actually configure the list. Mailman itself in operation doesn't get anything from any *.cfg file. Actual list configurations are in lists/*/config.pck. So, are you just putting something in some *.cfg file and that's it, or do you or some other custom process in your installation actually run bin/config_list or equivalent to transfer that information the the actual list configuration? If in fact, you have updated the list configuration such that the value of host_name visible on the list's General Options in the web admin interface or visible in the output from 'bin/config_list -o' or in the output from 'bin/dumpdb lists/list_name/config.pck' is the bracketed numeric IP address, and you still have the problem of it being changed, then I think it must be your outgoing MTA that is changing it, not Mailman. As far as I can tell, Mailman always uses the list's host_name attribute as the domain for email addresses. The only exception is for the site list in some cases where the email domain is obtained from the VIRTUAL_HOSTS dictionary which is built by add_virtualhost() directives in Defaults.py/mm_cfg.py. If you have not actually changed the list's host_name attribute because you've only changed some .cfg file and nothing more, then you need to actually update the list. ---------------------------------------------------------------------- Comment By: Daniel (doolyo) Date: 2005-11-09 01:34 Message: Logged In: YES user_id=1320890 The 'host_name' tag I am speaking about is in the /etc/mailman/*.cfg file (or /var/lib/mailman/data/*.cfg). I can make the host_name accept the squared brackets IP address without any problem. It stays there and it is properly placed in the file, it is not changed. However, when I send an e-mail to the list itself, then the e- mail is indicated to come from 'myhost.mydomain.com' instead of keeping '[142.56.2.72]'. That is my problem, because I would like people to be able to answer to this IP address instead of the host name, as this host name is not yet active due to the fact that I am configuring Mailman and testing it. Once it passes my tests, then the domain will be active, but I need this 'from' header containing this exact same '[142.56.2.72]' string than 'host_name' for the system to receive back the e-mails. Kind regards, Daniel ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-08 17:14 Message: Logged In: YES user_id=1123998 Can you be more specific? I have tested both Mailman 2.1.5 and 2.1.6 and they accept a host_name of the form [142.56.2.72] on the General Options page with no problem. Is your issue that you can't get General Options to accept a numeric IP in square brackets, or that it is accepted, but it gets 'changed' somewhere else. Please clarify, and if the latter, please be specific about where you observe the 'change'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1268939&group_id=103 From noreply at sourceforge.net Fri Nov 18 03:24:20 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Nov 2005 18:24:20 -0800 Subject: [ mailman-Patches-1347962 ] Sibling list: avoid duplicate mail Message-ID: Patches item #1347962, was opened at 2005-11-04 05:57 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1347962&group_id=103 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: Tokio Kikuchi (tkikuchi) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Sibling list: avoid duplicate mail Initial Comment: This patch enables to avoid sending duplicate mail if other list address is specified in to: or cc: header. - Sibling lists are other mailing lists on this site whose members are excluded from regular delivery if those list addresses appear in To: or Cc: header. - The list addresses should be witten in full mail address format (e.g. mailman at example.com). Do not specify the list address mutually in the sibling list configuration page or those doubled members won't get message. TBD: - Is the terminology 'sibling' appropriate? - Need more comments in the processing code (CalcRecips.py). ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-11-18 02:24 Message: Logged In: YES user_id=67709 On my second thought, I determined to add 'include' feature in this 'sibling list' idea. Also, the GUI is moved from Genral to NonDigest because I think it is more appropreate. - Exclude lists are the same as the original 'sibling lists' in the first post. - Include lists are the lists on the same mailman installation site whose members are included in the regular delivery if they are not appear in To: of Cc: header. Thus, it may work as 'umbrella list' if the lists are all in the same site. If you have already applied the first version of sibling.patch, you have to backout it before applying this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1347962&group_id=103 From noreply at sourceforge.net Fri Nov 18 03:37:29 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 17 Nov 2005 18:37:29 -0800 Subject: [ mailman-Patches-1220144 ] allow specifying another list in accept_these_nonmembers Message-ID: Patches item #1220144, was opened at 2005-06-14 06:29 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1220144&group_id=103 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.2 / 3.0 Status: Open Resolution: None >Priority: 6 Submitted By: Jim Tittsler (jtittsler) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: allow specifying another list in accept_these_nonmembers Initial Comment: Add the capability to logically include the addresses all of the members of another list in the same Mailman installation to accept_these_nonmembers. '@listname' checks the poster's address against the membership of listname. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-11-18 02:37 Message: Logged In: YES user_id=67709 Marking as an Mailman 2.2 new feature candidate. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1220144&group_id=103 From noreply at sourceforge.net Sat Nov 19 04:07:57 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 18 Nov 2005 19:07:57 -0800 Subject: [ mailman-Patches-1246003 ] 2.1.6 senddigests unicode error exception handling Message-ID: Patches item #1246003, was opened at 2005-07-27 13:12 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1246003&group_id=103 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: Closed >Resolution: Accepted Priority: 5 Submitted By: Auke Kok (sofar) Assigned to: Nobody/Anonymous (nobody) Summary: 2.1.6 senddigests unicode error exception handling Initial Comment: Hi, I've had senddigests break on me and this seems to be resolved by adding a proper exception handling as follows: vi +333 Mailman/Handlers/ToDigest.py replace: except LookupError: with: except (UnicodeError, LookupError): after this adjustment all digests are sent out properly again for my lists. symptoms were: 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 133, in send_digests send_i18n_digests(mlist, mboxfp) File "/var/mailman/Mailman/Handlers/ToDigest.py", line 331, in send_i18n_digests payload = unicode(payload, mcset, 'replace' UnicodeError: ISO-2022-JP decoding error: invalid designation ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-11-19 03:07 Message: Logged In: YES user_id=67709 Accepted and closed. Thank you. ---------------------------------------------------------------------- Comment By: Jonathan Polansky (polansky) Date: 2005-11-02 23:11 Message: Logged In: YES user_id=567517 I just wanted to add that I also ran into this error and this fix seems to have solved the problem. If this could be included in the next mm update, that'd be great. Also, thanks to Auke for the fix! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1246003&group_id=103 From noreply at sourceforge.net Tue Nov 22 06:26:00 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Nov 2005 21:26:00 -0800 Subject: [ mailman-Bugs-1363422 ] Valid E-mails Rejected as Invalid Message-ID: Bugs item #1363422, was opened at 2005-11-22 00:26 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=1363422&group_id=103 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: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Krellis (krellis) Assigned to: Nobody/Anonymous (nobody) Summary: Valid E-mails Rejected as Invalid Initial Comment: I ran into a problem recently with sync_members. I was attempting to add a list of addresses that included "---tim--- at krellis.org", but this address was rejected: bin/sync_members -a=no -f /usr/local/mailinglists/lists/system-status.txt system-status Invalid : ---tim--- at krellis.org You must fix the preceding invalid addresses first. While this is an ODD address, it is perfectly legal, per section 3.4 of RFC 2822 (http://www.faqs.org/rfcs/rfc2822.html). Rejecting a valid address like this seems like a pretty major problem to me. This was with MailMan 2.1.6 on FreeBSD 4. If there is any more information I can provide, please let me know. Regards, Tim Wilde ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1363422&group_id=103 From noreply at sourceforge.net Tue Nov 22 06:28:11 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Mon, 21 Nov 2005 21:28:11 -0800 Subject: [ mailman-Bugs-1363422 ] Valid E-mails Rejected as Invalid Message-ID: Bugs item #1363422, was opened at 2005-11-21 21:26 Message generated for change (Settings changed) made by krellis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1363422&group_id=103 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: (un)subscribing Group: 2.1 (stable) Status: Open Resolution: None >Priority: 7 Submitted By: Tim Wilde (krellis) Assigned to: Nobody/Anonymous (nobody) Summary: Valid E-mails Rejected as Invalid Initial Comment: I ran into a problem recently with sync_members. I was attempting to add a list of addresses that included "---tim--- at krellis.org", but this address was rejected: bin/sync_members -a=no -f /usr/local/mailinglists/lists/system-status.txt system-status Invalid : ---tim--- at krellis.org You must fix the preceding invalid addresses first. While this is an ODD address, it is perfectly legal, per section 3.4 of RFC 2822 (http://www.faqs.org/rfcs/rfc2822.html). Rejecting a valid address like this seems like a pretty major problem to me. This was with MailMan 2.1.6 on FreeBSD 4. If there is any more information I can provide, please let me know. Regards, Tim Wilde ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1363422&group_id=103 From noreply at sourceforge.net Wed Nov 23 00:31:48 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 15:31:48 -0800 Subject: [ mailman-Bugs-971957 ] Uncaught runner exception Message-ID: Bugs item #971957, was opened at 2004-06-12 23:36 Message generated for change (Comment added) made by gray-john You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=971957&group_id=103 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: John Distler (jd_waverly) Assigned to: Nobody/Anonymous (nobody) Summary: Uncaught runner exception Initial Comment: In 2.1.5 Apparently some email message characters can crash the Runner.py. I have inserted $mailman in place of my mailman path in the message below from $mailman/logs/error Jun 12 01:25:48 2004 (16604) Uncaught runner exception: ASCII decoding error: ordinal not in range (128) Jun 12 01:25:48 2004 (16604) Traceback (most recent call last): File "$mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File $mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "$mailman/Mailman/Queue/CommandRunner.py", line 223, in _dispose res = Results(mlist, msg, msgdata) File "$mailman/Mailman/Queue/CommandRunner.py", line 77, in __init__ subj = make_header(decode_header (subj)).__unicode__() File "$mailman/pythonlib/email/Header.py", line 144, in make_header h.append(s, charset) File "$mailman/pythonlib/email/Header.py", line 272, in append ustr = unicode(s, incodec, errors) UnicodeError: ASCII decoding error: ordinal not in range (128) ---------------------------------------------------------------------- Comment By: John Gray (gray-john) Date: 2005-11-22 18:31 Message: Logged In: YES user_id=392368 I'm seeing this in 2.1.6 as well. We are running Debian Sarge. Any word on getting this resolved? ---------------------------------------------------------------------- Comment By: Tommi Tervo (tomtervo) Date: 2004-07-30 09:42 Message: Logged In: YES user_id=1094436 Do you need some additional information for debugging this one, I've over 200 mails stuck on shunts. AFAIK this is quite fatal bug, emails just disappear and nobody gets notification. UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 10: ordinal not in range(128) Mailman 2.1.5 and python 2.3.4 on Solaris 8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=971957&group_id=103 From noreply at sourceforge.net Wed Nov 23 07:00:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Tue, 22 Nov 2005 22:00:07 -0800 Subject: [ mailman-Bugs-971957 ] Uncaught runner exception Message-ID: Bugs item #971957, was opened at 2004-06-12 20:36 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=971957&group_id=103 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: John Distler (jd_waverly) Assigned to: Nobody/Anonymous (nobody) Summary: Uncaught runner exception Initial Comment: In 2.1.5 Apparently some email message characters can crash the Runner.py. I have inserted $mailman in place of my mailman path in the message below from $mailman/logs/error Jun 12 01:25:48 2004 (16604) Uncaught runner exception: ASCII decoding error: ordinal not in range (128) Jun 12 01:25:48 2004 (16604) Traceback (most recent call last): File "$mailman/Mailman/Queue/Runner.py", line 111, in _oneloop self._onefile(msg, msgdata) File $mailman/Mailman/Queue/Runner.py", line 167, in _onefile keepqueued = self._dispose(mlist, msg, msgdata) File "$mailman/Mailman/Queue/CommandRunner.py", line 223, in _dispose res = Results(mlist, msg, msgdata) File "$mailman/Mailman/Queue/CommandRunner.py", line 77, in __init__ subj = make_header(decode_header (subj)).__unicode__() File "$mailman/pythonlib/email/Header.py", line 144, in make_header h.append(s, charset) File "$mailman/pythonlib/email/Header.py", line 272, in append ustr = unicode(s, incodec, errors) UnicodeError: ASCII decoding error: ordinal not in range (128) ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2005-11-22 22:00 Message: Logged In: YES user_id=1123998 gray-john wrote: > >I'm seeing this in 2.1.6 as well. We are running Debian >Sarge. Any word on getting this resolved? This error was fixed in source in 2.1.6 by catching and passing the UnicodeError exception. See bug 909490 which is the same problem. If you are seeing this error in 2.1.6, it must be coming from somewhere other than CommandRunner calling make_header. I suggest you try to get a resolution by posting your specific error trace to mailman-users at python.org. I'm closing this report. ---------------------------------------------------------------------- Comment By: John Gray (gray-john) Date: 2005-11-22 15:31 Message: Logged In: YES user_id=392368 I'm seeing this in 2.1.6 as well. We are running Debian Sarge. Any word on getting this resolved? ---------------------------------------------------------------------- Comment By: Tommi Tervo (tomtervo) Date: 2004-07-30 06:42 Message: Logged In: YES user_id=1094436 Do you need some additional information for debugging this one, I've over 200 mails stuck on shunts. AFAIK this is quite fatal bug, emails just disappear and nobody gets notification. UnicodeDecodeError: 'ascii' codec can't decode byte 0xf6 in position 10: ordinal not in range(128) Mailman 2.1.5 and python 2.3.4 on Solaris 8. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=971957&group_id=103 From noreply at sourceforge.net Thu Nov 24 06:19:59 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 21:19:59 -0800 Subject: [ mailman-Patches-1365282 ] Add New Langauge Punjabi (pa) to mailman Message-ID: Patches item #1365282, was opened at 2005-11-24 05:19 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=1365282&group_id=103 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: Amanpreet Singh Alam (aalam) Assigned to: Nobody/Anonymous (nobody) Summary: Add New Langauge Punjabi (pa) to mailman Initial Comment: Hello I translate mailman to Punajbi and Want to include in mailman. As per direction from Barry, I m attaching file here! following is info about Language "Punjabi" ISO Code = "pa" Coding = Unicode (UTF-8) Can u please include those files for Punjabi to Mailman? thanks AP Singh Alam http://punlinux.sf.net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1365282&group_id=103 From noreply at sourceforge.net Thu Nov 24 06:20:51 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 23 Nov 2005 21:20:51 -0800 Subject: [ mailman-Patches-1365282 ] Add New Langauge Punjabi (pa) to mailman Message-ID: Patches item #1365282, was opened at 2005-11-24 05:19 Message generated for change (Settings changed) made by aalam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1365282&group_id=103 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: Amanpreet Singh Alam (aalam) >Assigned to: Tokio Kikuchi (tkikuchi) Summary: Add New Langauge Punjabi (pa) to mailman Initial Comment: Hello I translate mailman to Punajbi and Want to include in mailman. As per direction from Barry, I m attaching file here! following is info about Language "Punjabi" ISO Code = "pa" Coding = Unicode (UTF-8) Can u please include those files for Punjabi to Mailman? thanks AP Singh Alam http://punlinux.sf.net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1365282&group_id=103 From noreply at sourceforge.net Sat Nov 26 07:32:06 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Fri, 25 Nov 2005 22:32:06 -0800 Subject: [ mailman-Patches-1365282 ] Add New Langauge Punjabi (pa) to mailman Message-ID: Patches item #1365282, was opened at 2005-11-24 05:19 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1365282&group_id=103 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: Amanpreet Singh Alam (aalam) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Add New Langauge Punjabi (pa) to mailman Initial Comment: Hello I translate mailman to Punajbi and Want to include in mailman. As per direction from Barry, I m attaching file here! following is info about Language "Punjabi" ISO Code = "pa" Coding = Unicode (UTF-8) Can u please include those files for Punjabi to Mailman? thanks AP Singh Alam http://punlinux.sf.net ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-11-26 06:32 Message: Logged In: YES user_id=67709 Hi, I tested your translation and get error. Will you please test your translation by yourself before submitting to the patch tracker? You should add your language in templates/Makefile.in, messages/Makefile.in and Mailman/Defaults.py.in then do the configure/make install. bin/transcheck should help debugging. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1365282&group_id=103 From noreply at sourceforge.net Sat Nov 26 15:58:34 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 26 Nov 2005 06:58:34 -0800 Subject: [ mailman-Bugs-815297 ] Breaking signatures in message/rfc822 attachement! Message-ID: Bugs item #815297, was opened at 2003-09-30 19:42 Message generated for change (Comment added) made by ber You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=815297&group_id=103 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: Open Resolution: None Priority: 8 Submitted By: Bernhard Reiter (ber) Assigned to: Nobody/Anonymous (nobody) Summary: Breaking signatures in message/rfc822 attachement! Initial Comment: Mailman _must_ not touch MIME-parts which are nested more deeply in the mail. As tested with Mailman 2.1.2, header lines will be sometimes reformatted in message/rfc822 attachments which will break the OpenPGP signature (also conforming to the PGP/MIME standard) on that part. I'm attaching a simple email with on long header. Forward this as MIME part and sign it sending it through Mailman, the signature will be broken. This is an email security affecting bug, because if people start believing that a *BAD* signature does not mean much, because they get many broken by mailman, they will not react to a seriously manipulated email anymore! ---------------------------------------------------------------------- >Comment By: Bernhard Reiter (ber) Date: 2005-11-26 15:58 Message: Logged In: YES user_id=113859 This is still a serious bug. I guess that the real fix will be to rewrite the email and mime handling classes to at least additionally save an original version of the different email parts without stripping and further formatting. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-05-10 20:15 Message: Logged In: YES user_id=113859 There is another possibility when mailman breaks the signature and that is when the signed part contains an empty header with _two_ spaces after the colon, like forward and sign an email with X-Empty-Header-with-two-spaces: patch 933757 does not remedy this, though. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2004-04-12 19:17 Message: Logged In: YES user_id=113859 I have created a patch to address the problem. [ 933757 ] fix for [815297] signatures break https://sourceforge.net/tracker/index.php?func=detail&aid=933757&group_id=103&atid=300103 ---------------------------------------------------------------------- Comment By: Marc Mutz (mmutz) Date: 2003-10-03 17:54 Message: Logged In: YES user_id=82377 This is not limited to message/rfc822 at all: As a specific example, create a message with an attachment and add the header Content-Disposition: attachment; filename="more-than-70-chars. txt" (all in a single line), then send it through a mailman-managed ml. Result: mailman "fixes" the message to look like Content-Disposition: attachment; \tfilename="more-than-70-chars.txt" It even does that inside a multipart/signed part, and this is where it breaks the signature verification. ---------------------------------------------------------------------- Comment By: Bernhard Reiter (ber) Date: 2003-09-30 19:46 Message: Logged In: YES user_id=113859 Here is the email signed by myself and broken after delivery through mailman. Check the "To:" header line. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=815297&group_id=103 From noreply at sourceforge.net Sun Nov 27 18:54:03 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 09:54:03 -0800 Subject: [ mailman-Bugs-1263213 ] checkbox "Send list created" not saved if failure Message-ID: Bugs item #1263213, was opened at 2005-08-18 09:50 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1263213&group_id=103 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: None Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Daniel (doolyo) Assigned to: Mark Sapiro (msapiro) Summary: checkbox "Send list created" not saved if failure Initial Comment: On the list creation page (/mailman/create), if we check the "Send list created e-mail to list owner" button to 'yes' and that we put a wrong password by submitting the form, the checkbox will come back to 'no'. This is not the case with the other checkboxes or the text, everything else comes back to the previously chosen values. ---------------------------------------------------------------------- Comment By: Daniel (doolyo) Date: 2005-11-09 01:53 Message: Logged In: YES user_id=1320890 Thanks for that, msapiro. Regards, Daniel ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-08 18:49 Message: Logged In: YES user_id=1123998 The attached patch fixes the bug including correctly initializing the button from DEFAULT_DEFAULT_MEMBER_MODERATION and remembering the prior choice across errors. There is still an issue in that language selections are not remembered across errors. ---------------------------------------------------------------------- Comment By: Daniel (doolyo) Date: 2005-08-18 11:49 Message: Logged In: YES user_id=1320890 Oops, sorry. It is not the correct checkbox. It is the other, called 'Should new members be quarantined before they are allowed to post unmoderated to this list?'. The rest is true for the fact that it looses it's 'yes' value. Thanks, Daniel ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1263213&group_id=103 From noreply at sourceforge.net Sun Nov 27 18:55:07 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 09:55:07 -0800 Subject: [ mailman-Patches-1318883 ] Line following Approved: line in body of post is stripped Message-ID: Patches item #1318883, was opened at 2005-10-08 14:12 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1318883&group_id=103 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: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Mark Sapiro (msapiro) Summary: Line following Approved: line in body of post is stripped Initial Comment: If a post contains an [Aa]pproved?: line as the first non-blank line of the first text/plain part (and doesn't contain an Approved?: header), the line itself is deleted, but so is the first of the remaining lines. If this first remaining line is a blank line which preceeded the Approved: line, no harm is done, but if there are no blank lines preceeding the Approved: line, the line following the Approved: line which may be non-blank is stripped. This occurs because after the Approved: line is removed, the remaining lines are re-joined beginning with line 1 and not line 0. The patch to Mailman/Handlers/Approve.py corrects this. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-12 18:46 Message: Logged In: YES user_id=1123998 Patch has been commited in CVS ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1318883&group_id=103 From noreply at sourceforge.net Sun Nov 27 18:56:04 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 09:56:04 -0800 Subject: [ mailman-Patches-1287921 ] post log entries show envelope sender, not From: Message-ID: Patches item #1287921, was opened at 2005-09-11 11:00 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287921&group_id=103 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: Closed >Resolution: Fixed Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Mark Sapiro (msapiro) Summary: post log entries show envelope sender, not From: Initial Comment: The interpolation dictionary used with the SMTPDirect.py log messages includes 'sender' which is obtained with the Message.get_sender() method. If mm_cfg.USE_ENVELOPE_SENDER is Yes, this method returns the envelope sender which, since this is an outgoing message, is always the listname-bounces address. Since 'listname' is already in the dictionary, this is redundant. It would be more useful, at least for lists which aren't anonymous, to override this behavior and get the sender with get_sender(use_envelope=0) which would return the From: address. The patch makes this change. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2005-11-12 16:01 Message: Logged In: YES user_id=1123998 This has been fixed differently from the patch that was here. The patch would always use the From:, but the fix correctly calls msg.get_sender() without forcing use_envelope=0; it just does it earlier. The fix is in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1287921&group_id=103 From noreply at sourceforge.net Sun Nov 27 23:26:16 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 14:26:16 -0800 Subject: [ mailman-Bugs-1367783 ] Content filtering encoded HTML to plain text garbles result Message-ID: Bugs item #1367783, was opened at 2005-11-27 14:26 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=1367783&group_id=103 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: Mark Sapiro (msapiro) Assigned to: Mark Sapiro (msapiro) Summary: Content filtering encoded HTML to plain text garbles result Initial Comment: If content filtering is on and convert_html_to_plaintext is yes and the HTML parts to be converted are base64 or quoted-printable encoded, the part is not decoded prior to passing to mm_cfg.HTML_TO_PLAIN_TEXT_COMMAND. This can result in the HTML not being converted at all if base64 encoded data 'passes through' mm_cfg.HTML_TO_PLAIN_TEXT_COMMAND, or the result being garbled if there are quoted-printable characters inside HTML tags. Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1367783&group_id=103 From noreply at sourceforge.net Sun Nov 27 23:27:25 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 14:27:25 -0800 Subject: [ mailman-Bugs-1367783 ] Content filtering encoded HTML to plain text garbles result Message-ID: Bugs item #1367783, was opened at 2005-11-27 14:26 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1367783&group_id=103 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: Fixed Priority: 5 Submitted By: Mark Sapiro (msapiro) Assigned to: Mark Sapiro (msapiro) Summary: Content filtering encoded HTML to plain text garbles result Initial Comment: If content filtering is on and convert_html_to_plaintext is yes and the HTML parts to be converted are base64 or quoted-printable encoded, the part is not decoded prior to passing to mm_cfg.HTML_TO_PLAIN_TEXT_COMMAND. This can result in the HTML not being converted at all if base64 encoded data 'passes through' mm_cfg.HTML_TO_PLAIN_TEXT_COMMAND, or the result being garbled if there are quoted-printable characters inside HTML tags. Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1367783&group_id=103 From noreply at sourceforge.net Sun Nov 27 23:27:56 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 14:27:56 -0800 Subject: [ mailman-Bugs-1367783 ] Content filtering encoded HTML to plain text garbles result Message-ID: Bugs item #1367783, was opened at 2005-11-27 14:26 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1367783&group_id=103 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: Mark Sapiro (msapiro) Assigned to: Mark Sapiro (msapiro) Summary: Content filtering encoded HTML to plain text garbles result Initial Comment: If content filtering is on and convert_html_to_plaintext is yes and the HTML parts to be converted are base64 or quoted-printable encoded, the part is not decoded prior to passing to mm_cfg.HTML_TO_PLAIN_TEXT_COMMAND. This can result in the HTML not being converted at all if base64 encoded data 'passes through' mm_cfg.HTML_TO_PLAIN_TEXT_COMMAND, or the result being garbled if there are quoted-printable characters inside HTML tags. Fixed in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1367783&group_id=103 From noreply at sourceforge.net Mon Nov 28 06:45:09 2005 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 27 Nov 2005 21:45:09 -0800 Subject: [ mailman-Patches-1365282 ] Add New Langauge Punjabi (pa) to mailman Message-ID: Patches item #1365282, was opened at 2005-11-24 05:19 Message generated for change (Comment added) made by aalam You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1365282&group_id=103 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: Amanpreet Singh Alam (aalam) Assigned to: Tokio Kikuchi (tkikuchi) Summary: Add New Langauge Punjabi (pa) to mailman Initial Comment: Hello I translate mailman to Punajbi and Want to include in mailman. As per direction from Barry, I m attaching file here! following is info about Language "Punjabi" ISO Code = "pa" Coding = Unicode (UTF-8) Can u please include those files for Punjabi to Mailman? thanks AP Singh Alam http://punlinux.sf.net ---------------------------------------------------------------------- >Comment By: Amanpreet Singh Alam (aalam) Date: 2005-11-28 05:45 Message: Logged In: YES user_id=1200839 I buid on Fedora and it was ready can u please help me to send the errors? thanks AP Singh ---------------------------------------------------------------------- Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-11-26 06:32 Message: Logged In: YES user_id=67709 Hi, I tested your translation and get error. Will you please test your translation by yourself before submitting to the patch tracker? You should add your language in templates/Makefile.in, messages/Makefile.in and Mailman/Defaults.py.in then do the configure/make install. bin/transcheck should help debugging. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1365282&group_id=103