Mailman 3 August 2005 - Mailman-coders

[ mailman-Bugs-1255548 ] Corrupt address -> message stuck in queue (endless loop)
by SourceForge.net Aug. 10, 2005

Aug. 10, 2005

Bugs item #1255548, was opened at 2005-08-10 03:27 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1255548&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: bounce detection Group: 2.0.x >Status: Closed Resolution: None Priority: 5 Submitted By: mpellissetti (mpellissetti) Assigned to: Nobody/Anonymous (nobody) Summary: Corrupt address -> message stuck in queue (endless loop) Initial Comment: Version: mailman-2.0.8-1, on Red Hat Linux 7.2 We transferred email adresses from a Windows-based program (Filemaker), by exporting them in an ASCII file (Addresses.txt) and importing them to the mailman list with: /var/mailman/bin/remove_members -a Listname; /var/mailman/bin/add_members -n Addresses.txt Listname The file Addresses.txt contained one corrupt email address of the form: user1(a)host.domain^Kpers: user2(a)host.domain Viewing the file content with od showed the following exact character sequence (separate characters with one blank for better viewing): u s e r 1 @ h o s t . d o m a i n \v p e r s : u s e r 2 @ h o s t . d o m a i n Note: The corrupt address was not detected by mailman when it was imported! Sending an email to this mailing list caused the message to be stuck in /var/mailman/qfiles. Since qrunner is specified in /var/mailman/cron/crontab.in to be executed every minute, the message was sent out repeatedly (18 times mailman was killed manually) basically to the addresses preceding the corrupt one. The sender of the message received the following error message per email: ... ----- The following addresses had permanent fatal errors ----- pers: ----- Transcript of session follows ----- 553 5.1.3 pers:... List:; syntax illegal for recipient addresses ... Note: This bug is reproducible. This behavior denotes poor fault tolerance, I strongly hope that newer versions behave differently in such a case. It is always possible that a corrupt address is being entered, but the consequences (in the described case) are catastrophic! (Fortunately one of the approx. 500 recipients replied quite immediately, so "only" 18 copies of the message were sent out!) ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2005-08-10 08:04 Message: Logged In: YES user_id=12800 Mailman 2.0.8 is extremely old and no longer supported. If you upgrade to Mailman 2.1.6 (the current release of the 2.1 branch) and the problem persists, then feel free to open a new bug report, but please try to include the content of the offending message so that we can debug it. ---------------------------------------------------------------------- Comment By: mpellissetti (mpellissetti) Date: 2005-08-10 03:35 Message: Logged In: YES user_id=1326612 Rectification: After the message got stuck in /var/mailman/qfiles, the message was sent out repeatedly (18 times until mailman was killed manually), basically to the addresses FOLLOWING the corrupt one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1255548&group_…

1 0

[ mailman-Bugs-1255548 ] Corrupt address -> message stuck in queue (endless loop)
by SourceForge.net Aug. 10, 2005

Aug. 10, 2005

Bugs item #1255548, was opened at 2005-08-10 09:27 Message generated for change (Comment added) made by mpellissetti You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1255548&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: bounce detection Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: mpellissetti (mpellissetti) Assigned to: Nobody/Anonymous (nobody) Summary: Corrupt address -> message stuck in queue (endless loop) Initial Comment: Version: mailman-2.0.8-1, on Red Hat Linux 7.2 We transferred email adresses from a Windows-based program (Filemaker), by exporting them in an ASCII file (Addresses.txt) and importing them to the mailman list with: /var/mailman/bin/remove_members -a Listname; /var/mailman/bin/add_members -n Addresses.txt Listname The file Addresses.txt contained one corrupt email address of the form: user1(a)host.domain^Kpers: user2(a)host.domain Viewing the file content with od showed the following exact character sequence (separate characters with one blank for better viewing): u s e r 1 @ h o s t . d o m a i n \v p e r s : u s e r 2 @ h o s t . d o m a i n Note: The corrupt address was not detected by mailman when it was imported! Sending an email to this mailing list caused the message to be stuck in /var/mailman/qfiles. Since qrunner is specified in /var/mailman/cron/crontab.in to be executed every minute, the message was sent out repeatedly (18 times mailman was killed manually) basically to the addresses preceding the corrupt one. The sender of the message received the following error message per email: ... ----- The following addresses had permanent fatal errors ----- pers: ----- Transcript of session follows ----- 553 5.1.3 pers:... List:; syntax illegal for recipient addresses ... Note: This bug is reproducible. This behavior denotes poor fault tolerance, I strongly hope that newer versions behave differently in such a case. It is always possible that a corrupt address is being entered, but the consequences (in the described case) are catastrophic! (Fortunately one of the approx. 500 recipients replied quite immediately, so "only" 18 copies of the message were sent out!) ---------------------------------------------------------------------- >Comment By: mpellissetti (mpellissetti) Date: 2005-08-10 09:35 Message: Logged In: YES user_id=1326612 Rectification: After the message got stuck in /var/mailman/qfiles, the message was sent out repeatedly (18 times until mailman was killed manually), basically to the addresses FOLLOWING the corrupt one. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1255548&group_…

1 0

[ mailman-Bugs-1255548 ] Corrupt address -> message stuck in queue (endless loop)
by SourceForge.net Aug. 10, 2005

Aug. 10, 2005

Bugs item #1255548, was opened at 2005-08-10 09:27 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=1255548&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: bounce detection Group: 2.0.x Status: Open Resolution: None Priority: 5 Submitted By: mpellissetti (mpellissetti) Assigned to: Nobody/Anonymous (nobody) Summary: Corrupt address -> message stuck in queue (endless loop) Initial Comment: Version: mailman-2.0.8-1, on Red Hat Linux 7.2 We transferred email adresses from a Windows-based program (Filemaker), by exporting them in an ASCII file (Addresses.txt) and importing them to the mailman list with: /var/mailman/bin/remove_members -a Listname; /var/mailman/bin/add_members -n Addresses.txt Listname The file Addresses.txt contained one corrupt email address of the form: user1(a)host.domain^Kpers: user2(a)host.domain Viewing the file content with od showed the following exact character sequence (separate characters with one blank for better viewing): u s e r 1 @ h o s t . d o m a i n \v p e r s : u s e r 2 @ h o s t . d o m a i n Note: The corrupt address was not detected by mailman when it was imported! Sending an email to this mailing list caused the message to be stuck in /var/mailman/qfiles. Since qrunner is specified in /var/mailman/cron/crontab.in to be executed every minute, the message was sent out repeatedly (18 times mailman was killed manually) basically to the addresses preceding the corrupt one. The sender of the message received the following error message per email: ... ----- The following addresses had permanent fatal errors ----- pers: ----- Transcript of session follows ----- 553 5.1.3 pers:... List:; syntax illegal for recipient addresses ... Note: This bug is reproducible. This behavior denotes poor fault tolerance, I strongly hope that newer versions behave differently in such a case. It is always possible that a corrupt address is being entered, but the consequences (in the described case) are catastrophic! (Fortunately one of the approx. 500 recipients replied quite immediately, so "only" 18 copies of the message were sent out!) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1255548&group_…

1 0

[ mailman-Feature Requests-1253550 ] Pls add red colour background with oversized messages
by SourceForge.net Aug. 7, 2005

Aug. 7, 2005

Feature Requests item #1253550, was opened at 2005-08-07 15:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1253550&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Loek Jehee (loekjehe) Assigned to: Nobody/Anonymous (nobody) Summary: Pls add red colour background with oversized messages Initial Comment: Hello, I use MailMan 2.1.6 for a Buddhist moderated mailinglist of 1440 subscribers. I am the moderator of the list and all posts have to be approved by me. I have put the maximum length of a message body in the General Options to 120 KB because I receive many complaints when too large messages are placed on the list. Unfortunately, MailMan in some cases does not give me a warning if a message is too large, e.g. if the message is done by a non-member of the list. In such cases these warnings seem to overrule the "too large" warning. It then is very easy for me to overlook the fact that a certain message is too large (>120 KB). I must then really read the Size field very well and that is an easy thing to forget. If I then by accident approve such message, this approval overrules the 120 KB setting in the General Options and the message thus is sent to the list (causing much irritation with some subscribers). That is why I would like to suggest to add in a future release of MailMan the feature, that all messages that are over the size as indicated in the General Options, show up in the "pending moderator requests" window with a light red coloured background. This should not be a difficult addition and it would be extremely beneficial for me to protect me against accidently approving oversized messages! It would also help if you give messages from non-members a yellow colour, etc. there are more possibilities there. But the red warning is crucial! Thank you and keep up the good work! Loek ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1253550&group_…

1 0

[ mailman-Bugs-1250657 ] header_filter_rules should use multiline mode
by SourceForge.net Aug. 3, 2005

Aug. 3, 2005

Bugs item #1250657, was opened at 2005-08-02 23:12 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1250657&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: security/privacy Group: 2.1 (stable) >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Iain Pople (iainpople) Assigned to: Nobody/Anonymous (nobody) Summary: header_filter_rules should use multiline mode Initial Comment: I have noticed some unexpected behaviour with header_filter_rules. I wanted to reject messages with an empty subject line so i came up with the following regex: ^subject:\s*$ However it wasn't working as desired. After delving around in the SpamDetect.py code i noticed that the re.search call is not using MULTILINE mode. So the headers are treated as one long string and ^ would only match the beginning of the string. Is this the desired behaviour? To me it makes more sense that it should use multiline mode. i.e.: --- SpamDetect.py.bak 2005-08-02 15:56:42.083270000 +1000 +++ SpamDetect.py 2005-08-02 17:33:59.698226000 +1000 @@ -127,7 +127,7 @@ for pattern in patterns.splitlines(): if pattern.startswith('#'): continue - if re.search(pattern, headers, re.IGNORECASE): + if re.search(pattern, headers, re.IGNORECASE| re.MULTILINE): if action == mm_cfg.DISCARD: raise Errors.DiscardMessage if action == mm_cfg.REJECT: @@ -137,3 +137,4 @@ hold_for_approval(mlist, msg, msgdata, HeaderMatchHold) if action == mm_cfg.ACCEPT: return ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2005-08-04 04:10 Message: Logged In: YES user_id=67709 Thank you! This was fixed in CVS. There may be some incompatibilities with this fix but my trivial example (in the Mailman FAQ Wizard 3.51) passed a test. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1250657&group_…

1 0

[ mailman-Patches-1244799 ] XML-RPC interface to Mailman
by SourceForge.net Aug. 3, 2005

Aug. 3, 2005

Patches item #1244799, was opened at 2005-07-25 21:29 Message generated for change (Comment added) made by jtate You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1244799&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 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: Joseph Tate (jtate) Date: 2005-08-03 15: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 14: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_…

1 0

[ mailman-Feature Requests-1251109 ] use css for presentation of content
by SourceForge.net Aug. 3, 2005

Aug. 3, 2005

Feature Requests item #1251109, was opened at 2005-08-03 17:32 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1251109&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: skripi (skripi) Assigned to: Nobody/Anonymous (nobody) Summary: use css for presentation of content Initial Comment: Hi, i tried to customize the mailman templates and noticed that a lot of presenation is hard-coded into the html-code. I was wondering if it would be possible to split the structure and the representation by using css. As while using css, the pages could more easily be changed in their representation. Maybe you could give it a thought. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1251109&group_…

1 0

[ mailman-Bugs-1251101 ] cgi generated pages do not produce valid html
by SourceForge.net Aug. 3, 2005

Aug. 3, 2005

Bugs item #1251101, was opened at 2005-08-03 17:25 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=1251101&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Web/CGI Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: skripi (skripi) Assigned to: Nobody/Anonymous (nobody) Summary: cgi generated pages do not produce valid html Initial Comment: Hi, i ran 'http://www.htmlhelp.com/cgi-bin/validate.cgi? url=http%3A%2F%2Fv1837.vanager. de&warnings=yes&input=yes&spider=yes&hidevalid=yes " against my local mailman installation and noticed: - the cgi's do not produce a proper doctype - the mailinglist templates are no longer html conform. Possible solution: prepend to all generated pages a DOCTYPE: --- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01// EN" "http://www.w3.org/TR/html4/strict.dtd"> --- or ---- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose. dtd"> --- I would prefer strict and move presentation related stuff to css.. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1251101&group_…

1 0

[ mailman-Bugs-1250657 ] header_filter_rules should use multiline mode
by SourceForge.net Aug. 2, 2005

Aug. 2, 2005

Bugs item #1250657, was opened at 2005-08-02 23:12 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=1250657&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: security/privacy Group: 2.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Iain Pople (iainpople) Assigned to: Nobody/Anonymous (nobody) Summary: header_filter_rules should use multiline mode Initial Comment: I have noticed some unexpected behaviour with header_filter_rules. I wanted to reject messages with an empty subject line so i came up with the following regex: ^subject:\s*$ However it wasn't working as desired. After delving around in the SpamDetect.py code i noticed that the re.search call is not using MULTILINE mode. So the headers are treated as one long string and ^ would only match the beginning of the string. Is this the desired behaviour? To me it makes more sense that it should use multiline mode. i.e.: --- SpamDetect.py.bak 2005-08-02 15:56:42.083270000 +1000 +++ SpamDetect.py 2005-08-02 17:33:59.698226000 +1000 @@ -127,7 +127,7 @@ for pattern in patterns.splitlines(): if pattern.startswith('#'): continue - if re.search(pattern, headers, re.IGNORECASE): + if re.search(pattern, headers, re.IGNORECASE| re.MULTILINE): if action == mm_cfg.DISCARD: raise Errors.DiscardMessage if action == mm_cfg.REJECT: @@ -137,3 +137,4 @@ hold_for_approval(mlist, msg, msgdata, HeaderMatchHold) if action == mm_cfg.ACCEPT: return ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1250657&group_…

1 0

problem with regular expression
by shay ben michael Aug. 1, 2005

Aug. 1, 2005

hello I have a regular expression run on a massive text. the results are fed into an iteraton (by finditer). for some reason I can't iterate it. (the program is stucked ). what is the reason (may the reason be there are non ASCII characters) how can I solve that. in case you are not able to answer can you give me please a link of a good forum desperatly waiting for answer thank in advance shay

1 0