Mailman-coders November 2005

mailman-coders@python.org

1 participants
52 discussions

[ mailman-Bugs-1263239 ] Mailman on SSL sends passwords in plain text
by SourceForge.net 06 Nov '05

06 Nov '05

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_… 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_…

1 0

[ mailman-Patches-1123383 ] Daily Status Report script...
by SourceForge.net 06 Nov '05

06 Nov '05

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_… 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_…

1 0

[ mailman-Patches-1347962 ] Sibling list: avoid duplicate mail
by SourceForge.net 03 Nov '05

03 Nov '05

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_… 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(a)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_…

1 0

[ mailman-Bugs-1269067 ] e-mail command confirmations should be optional
by SourceForge.net 03 Nov '05

03 Nov '05

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_… 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_…

1 0

[ mailman-Bugs-1269067 ] e-mail command confirmations should be optional
by SourceForge.net 03 Nov '05

03 Nov '05

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_… 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_…

1 0

[ mailman-Bugs-1345599 ] Unsubscribed users continue to receive reminders
by SourceForge.net 02 Nov '05

02 Nov '05

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_… 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 <http://www.list.org/mailman-install/node41.html> 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@domain' can receive a password reminder for 'list@domain' from 'mailman-owner@domain'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1345599&group_…

1 0

[ mailman-Bugs-1345599 ] Unsubscribed users continue to receive reminders
by SourceForge.net 02 Nov '05

02 Nov '05

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_… 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@domain' can receive a password reminder for 'list@domain' from 'mailman-owner@domain'. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1345599&group_…

1 0

[ mailman-Bugs-1345599 ] Unsubscribed users continue to receive reminders
by SourceForge.net 02 Nov '05

02 Nov '05

1 0

[ mailman-Patches-1246003 ] 2.1.6 senddigests unicode error exception handling
by SourceForge.net 02 Nov '05

02 Nov '05

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_… 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_…

1 0

[ mailman-Bugs-1345599 ] Unsubscribed users continue to receive reminders
by SourceForge.net 01 Nov '05

01 Nov '05

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_… 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_…

1 0

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

Mailman-coders November 2005