Mailman 3 September 2006 - Mailman-coders

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

Aug. 19, 2022

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

2 1

[ mailman-Bugs-1567408 ] Admin address over quota causes bounce loop
by SourceForge.net Sept. 29, 2006

Sept. 29, 2006

Bugs item #1567408, was opened at 2006-09-28 18:30 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1567408&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.1 (stable) Status: Open Resolution: None Priority: 5 Submitted By: Bron Gondwana (brong) Assigned to: Mark Sapiro (msapiro) Summary: Admin address over quota causes bounce loop Initial Comment: X-Mailman-Version: 2.1.9.cp1 Hi, I'm not the administrator of the Mailman instance, just the poor sysadmin of a mail service who was woken in the middle of the night by our MX servers being severely overloaded by a mail loop. One of our users hit their quota in Cyrus and hence their mail was bouncing. This user is the admin for a Mailman list, and the list has been configured to forward all bounces to the admin. The message was: --===============2109117388== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit As list administrator, your authorization is requested for the following mailing list posting: List: ***** From: ***** Subject: ***** Reason: Message body is too big: 7519566 bytes with a limit of 40 KB At your convenience, visit: http://... to approve or deny the request. And above that stacks of: --===============0756822160== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message was received as a bounce, but either the bounce format was not recognized, or no member addresses could be extracted from it. This mailing list has been configured to send all unrecognized bounce messages to the list administrator(s). For more information see: http://.../bounce I will point the owners of the offending bug at this thread so they can provide more specific information if they wish, without giving their privacy away. Bron. ---------------------------------------------------------------------- Comment By: Mark Sapiro (msapiro) Date: 2006-09-28 19:56 Message: Logged In: YES user_id=1123998 I am moving this to bugs as it is a bug report, not a patch. Your list owners don't need to provide any additional information. I understand exactly what's happening here. (but see below) There are two issues. The first is that we don't protect against this loop and I think we should try to. I'll look into fixing it, although I suspect it will not be easy as anything I might put in the 'unrecognized bounce' message to try to detect a loop can be munged or dropped by the MTA that returns the next bounce. The other part of the issue is that the MTA that is returning the 'over quota' denial is not returning an RFC 3464 or RFC 1894 compliant DSN or any of the many other formats that Mailman heuristically recognizes. If it were, it would be recognized and not sent back to the list owner. There is one thing you can provide and that is the actual 'delivery status' part of the unrecognized bounce. You can alter addresses and domains if you wish for privacy, but if I have the exact message including headers, I can add a recognizer for it. What I need is the contents of the message/rfc822 part that follows the "The attached message was received" notice you quote above up to the first "original message follows". I.e., just the DSN part and it's headers, not any of the multiple preceeding messages/DSNs/etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1567408&group_…

1 0

[ mailman-Patches-534298 ] forward unhandled bounces to admin
by SourceForge.net Sept. 29, 2006

Sept. 29, 2006

Patches item #534298, was opened at 2002-03-25 00:18 Message generated for change (Comment added) made by mbp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534298&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: list administration Group: Mailman 2.0.x Status: Closed Resolution: Out of Date Priority: 1 Submitted By: Martin Pool (mbp) Assigned to: Nobody/Anonymous (nobody) Summary: forward unhandled bounces to admin Initial Comment: samba.org handles a lot of mail messages, and therefore suffers a lot of bounced messages. Mailman's automatic bounce handling is great, but the problem is that people keep dreaming up new and wierd bounce messages. With Mailman 2.0.8, if I turn on automatic bounce handling then some bouncing addresses are not correctly detected and therefore keep generating large amounts of traffic indefinitely. If I turn it off, we get about 3000 bounces per day. Some of these are just not handled yet by the BouncerAPI and need patches. In some cases there is in fact no deterministic way to work out the bouncing address (at least until we have VERP), and human intervention is required. For example, Novell's brilliant mail software includes no information in the Received lines or bounce message to indicate what the bouncing address is! Anyhow, this patch changes the behaviour of the bounce handler so that bounce messages which do not cause any positive action are forwarded to the list administrator. "Positive action" can mean noticing that the address is already disabled, or marking it as bouncing, or similar things. It doesn't include addresses which don't seem to be on the list, which probably means that we have not interpreted the message properly and more help is required. So in summary bounces which can be automatically handled will be, and others will go to the admin. I'm not sure this is the perfect behaviour, but it certainly seems like an improvement. Perhaps you want to make it more configurable. Please merge this, or something like it. ---------------------------------------------------------------------- >Comment By: Martin Pool (mbp) Date: 2006-09-29 13:29 Message: Logged In: YES user_id=521 > Does this make you responsible for this behaviour? Since my patch was closed/out-of-date, presumably not. At any rate the behaviour is optional. > (consider the case where the admin addres is bouncing) Are you suggesting it will loop? I'm not sure whether admin messages are subject to normal bounce processing, but I think not. Anyhow, it will make it obvious that you need to fix the admin address. :) ---------------------------------------------------------------------- Comment By: Bron Gondwana (brong) Date: 2006-09-29 11:15 Message: Logged In: YES user_id=9941 Does this make you responsible for this behaviour? Next time you're down in Melbourne remind me to buy you a beer and tip it over you. (consider the case where the admin addres is bouncing) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-12 11:48 Message: Logged In: YES user_id=34209 As mentioned in email, I'll re-check the other bounce-detection patches, but the ones I checked didn't apply to 2.1 for other reasons as well (like their original module being completely rewritten.) ---------------------------------------------------------------------- Comment By: Martin Pool (mbp) Date: 2003-03-12 11:43 Message: Logged In: YES user_id=521 > Yeah, Mailman 2.1's bounce detection and handling was > largely rewritten. It also uses VERP now, so it should solve > most of your bounce problems, if not all. Yes, we're using VERP now and it's beautiful. In particular we have a lot of Exchange subscribers, and their bounce messages are nearly unintelligible. > I'm going to close this patch, as well as your other pending > bounce-detection patches, but if you see any new unhandled bounces > (or find that previously-reported ones still fail to detect) please > do open a new bug- or patch-report. I am OK about closing this one, but please reopen the others. Since Mailman still has the option of using a bounce parser rather than VERP it seems to make sense to have the parser be as smart as possible. Some people might not want to use VERP. Unless the patches no longer merge, I would encourage you to put them in. > (Preferably with an example message for us to test on.) I will do that in future. I think that was not mentioned when I sent them, though I do think the patches have partial examples in their comments. > I promise we wont let it rest as long as this one has. :-) Thanks. I know it can be hard to get around to these things. -- Martin ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-12 11:19 Message: Logged In: YES user_id=34209 Yeah, Mailman 2.1's bounce detection and handling was largely rewritten. It also uses VERP now, so it should solve most of your bounce problems, if not all. I'm going to close this patch, as well as your other pending bounce-detection patches, but if you see any new unhandled bounces (or find that previously-reported ones still fail to detect) please do open a new bug- or patch-report. (Preferably with an example message for us to test on.) I promise we wont let it rest as long as this one has. :-) ---------------------------------------------------------------------- Comment By: Martin Pool (mbp) Date: 2003-03-11 12:16 Message: Logged In: YES user_id=521 This seems to be already fixed in 2.1. ---------------------------------------------------------------------- Comment By: Martin Pool (mbp) Date: 2002-04-03 12:18 Message: Logged In: YES user_id=521 Tim, that's not quite so much of a problem as you might think. When excessive bounces are detected Mailman only *disables* addresses rather than removing them. With or without this patch, bouncing addresses which are already disabled are noted in the log file and not further action is taken. Problems can occur if the address is actually removed. This can arise in two ways. One way is that the mail administrator might explicitly remove the user from the list because of manual bounce processing. In that case, any later bounces will also go through to the admin. That's the reason for my patch to add --disable to remove_members. Secondly, users might unsubscribe themselves and then have their address start bouncing. You can imagine Mailman remembering previously-subscribed members so that it could handle these cases, but that's a much bigger project, and probably best done in conjunction with VERP. ---------------------------------------------------------------------- Comment By: Martin Pool (mbp) Date: 2002-03-25 12:03 Message: Logged In: YES user_id=521 This patch modifies the behaviour when handling bounce messages with multiple addresses, such as from Postfix. Now messages in which any of the bouncing addresses cannot be automatically handled are forwarded to the administrator. Eventually it might be nice to put a notice in the message explaining the problem -- e.g. user not found, is not a member, etc. This update also makes "digester lucked out" be considered successful processing. ---------------------------------------------------------------------- Comment By: Tim Potter (tpot) Date: 2002-03-25 10:18 Message: Logged In: YES user_id=9949 The scenario where addresses which don't seem to be on the list can be caused by bounces received after the user has been disabled due to the size of the mail queue. It may cause confusion forwarding them to the admin as there is nothing they can do about it except puzzle over why it was received. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534298&group_i…

1 0

[ mailman-Bugs-1567408 ] Admin address over quota causes bounce loop
by SourceForge.net Sept. 29, 2006

Sept. 29, 2006

Bugs item #1567408, was opened at 2006-09-28 18:30 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1567408&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: Bron Gondwana (brong) >Assigned to: Mark Sapiro (msapiro) Summary: Admin address over quota causes bounce loop Initial Comment: X-Mailman-Version: 2.1.9.cp1 Hi, I'm not the administrator of the Mailman instance, just the poor sysadmin of a mail service who was woken in the middle of the night by our MX servers being severely overloaded by a mail loop. One of our users hit their quota in Cyrus and hence their mail was bouncing. This user is the admin for a Mailman list, and the list has been configured to forward all bounces to the admin. The message was: --===============2109117388== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit As list administrator, your authorization is requested for the following mailing list posting: List: ***** From: ***** Subject: ***** Reason: Message body is too big: 7519566 bytes with a limit of 40 KB At your convenience, visit: http://... to approve or deny the request. And above that stacks of: --===============0756822160== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message was received as a bounce, but either the bounce format was not recognized, or no member addresses could be extracted from it. This mailing list has been configured to send all unrecognized bounce messages to the list administrator(s). For more information see: http://.../bounce I will point the owners of the offending bug at this thread so they can provide more specific information if they wish, without giving their privacy away. Bron. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-09-28 19:56 Message: Logged In: YES user_id=1123998 I am moving this to bugs as it is a bug report, not a patch. Your list owners don't need to provide any additional information. I understand exactly what's happening here. (but see below) There are two issues. The first is that we don't protect against this loop and I think we should try to. I'll look into fixing it, although I suspect it will not be easy as anything I might put in the 'unrecognized bounce' message to try to detect a loop can be munged or dropped by the MTA that returns the next bounce. The other part of the issue is that the MTA that is returning the 'over quota' denial is not returning an RFC 3464 or RFC 1894 compliant DSN or any of the many other formats that Mailman heuristically recognizes. If it were, it would be recognized and not sent back to the list owner. There is one thing you can provide and that is the actual 'delivery status' part of the unrecognized bounce. You can alter addresses and domains if you wish for privacy, but if I have the exact message including headers, I can add a recognizer for it. What I need is the contents of the message/rfc822 part that follows the "The attached message was received" notice you quote above up to the first "original message follows". I.e., just the DSN part and it's headers, not any of the multiple preceeding messages/DSNs/etc. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1567408&group_…

1 0

[ mailman-Patches-1567408 ] Admin address over quota causes bounce loop
by SourceForge.net Sept. 29, 2006

Sept. 29, 2006

Patches item #1567408, was opened at 2006-09-29 11:30 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=1567408&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 processing Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Submitted By: Bron Gondwana (brong) Assigned to: Nobody/Anonymous (nobody) Summary: Admin address over quota causes bounce loop Initial Comment: X-Mailman-Version: 2.1.9.cp1 Hi, I'm not the administrator of the Mailman instance, just the poor sysadmin of a mail service who was woken in the middle of the night by our MX servers being severely overloaded by a mail loop. One of our users hit their quota in Cyrus and hence their mail was bouncing. This user is the admin for a Mailman list, and the list has been configured to forward all bounces to the admin. The message was: --===============2109117388== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit As list administrator, your authorization is requested for the following mailing list posting: List: ***** From: ***** Subject: ***** Reason: Message body is too big: 7519566 bytes with a limit of 40 KB At your convenience, visit: http://... to approve or deny the request. And above that stacks of: --===============0756822160== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit The attached message was received as a bounce, but either the bounce format was not recognized, or no member addresses could be extracted from it. This mailing list has been configured to send all unrecognized bounce messages to the list administrator(s). For more information see: http://.../bounce I will point the owners of the offending bug at this thread so they can provide more specific information if they wish, without giving their privacy away. Bron. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1567408&group_…

1 0

[ mailman-Patches-534298 ] forward unhandled bounces to admin
by SourceForge.net Sept. 29, 2006

Sept. 29, 2006

Patches item #534298, was opened at 2002-03-25 00:18 Message generated for change (Comment added) made by brong You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534298&group_i… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: list administration Group: Mailman 2.0.x Status: Closed Resolution: Out of Date Priority: 1 Submitted By: Martin Pool (mbp) Assigned to: Nobody/Anonymous (nobody) Summary: forward unhandled bounces to admin Initial Comment: samba.org handles a lot of mail messages, and therefore suffers a lot of bounced messages. Mailman's automatic bounce handling is great, but the problem is that people keep dreaming up new and wierd bounce messages. With Mailman 2.0.8, if I turn on automatic bounce handling then some bouncing addresses are not correctly detected and therefore keep generating large amounts of traffic indefinitely. If I turn it off, we get about 3000 bounces per day. Some of these are just not handled yet by the BouncerAPI and need patches. In some cases there is in fact no deterministic way to work out the bouncing address (at least until we have VERP), and human intervention is required. For example, Novell's brilliant mail software includes no information in the Received lines or bounce message to indicate what the bouncing address is! Anyhow, this patch changes the behaviour of the bounce handler so that bounce messages which do not cause any positive action are forwarded to the list administrator. "Positive action" can mean noticing that the address is already disabled, or marking it as bouncing, or similar things. It doesn't include addresses which don't seem to be on the list, which probably means that we have not interpreted the message properly and more help is required. So in summary bounces which can be automatically handled will be, and others will go to the admin. I'm not sure this is the perfect behaviour, but it certainly seems like an improvement. Perhaps you want to make it more configurable. Please merge this, or something like it. ---------------------------------------------------------------------- Comment By: Bron Gondwana (brong) Date: 2006-09-29 11:15 Message: Logged In: YES user_id=9941 Does this make you responsible for this behaviour? Next time you're down in Melbourne remind me to buy you a beer and tip it over you. (consider the case where the admin addres is bouncing) ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-12 11:48 Message: Logged In: YES user_id=34209 As mentioned in email, I'll re-check the other bounce-detection patches, but the ones I checked didn't apply to 2.1 for other reasons as well (like their original module being completely rewritten.) ---------------------------------------------------------------------- Comment By: Martin Pool (mbp) Date: 2003-03-12 11:43 Message: Logged In: YES user_id=521 > Yeah, Mailman 2.1's bounce detection and handling was > largely rewritten. It also uses VERP now, so it should solve > most of your bounce problems, if not all. Yes, we're using VERP now and it's beautiful. In particular we have a lot of Exchange subscribers, and their bounce messages are nearly unintelligible. > I'm going to close this patch, as well as your other pending > bounce-detection patches, but if you see any new unhandled bounces > (or find that previously-reported ones still fail to detect) please > do open a new bug- or patch-report. I am OK about closing this one, but please reopen the others. Since Mailman still has the option of using a bounce parser rather than VERP it seems to make sense to have the parser be as smart as possible. Some people might not want to use VERP. Unless the patches no longer merge, I would encourage you to put them in. > (Preferably with an example message for us to test on.) I will do that in future. I think that was not mentioned when I sent them, though I do think the patches have partial examples in their comments. > I promise we wont let it rest as long as this one has. :-) Thanks. I know it can be hard to get around to these things. -- Martin ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2003-03-12 11:19 Message: Logged In: YES user_id=34209 Yeah, Mailman 2.1's bounce detection and handling was largely rewritten. It also uses VERP now, so it should solve most of your bounce problems, if not all. I'm going to close this patch, as well as your other pending bounce-detection patches, but if you see any new unhandled bounces (or find that previously-reported ones still fail to detect) please do open a new bug- or patch-report. (Preferably with an example message for us to test on.) I promise we wont let it rest as long as this one has. :-) ---------------------------------------------------------------------- Comment By: Martin Pool (mbp) Date: 2003-03-11 12:16 Message: Logged In: YES user_id=521 This seems to be already fixed in 2.1. ---------------------------------------------------------------------- Comment By: Martin Pool (mbp) Date: 2002-04-03 12:18 Message: Logged In: YES user_id=521 Tim, that's not quite so much of a problem as you might think. When excessive bounces are detected Mailman only *disables* addresses rather than removing them. With or without this patch, bouncing addresses which are already disabled are noted in the log file and not further action is taken. Problems can occur if the address is actually removed. This can arise in two ways. One way is that the mail administrator might explicitly remove the user from the list because of manual bounce processing. In that case, any later bounces will also go through to the admin. That's the reason for my patch to add --disable to remove_members. Secondly, users might unsubscribe themselves and then have their address start bouncing. You can imagine Mailman remembering previously-subscribed members so that it could handle these cases, but that's a much bigger project, and probably best done in conjunction with VERP. ---------------------------------------------------------------------- Comment By: Martin Pool (mbp) Date: 2002-03-25 12:03 Message: Logged In: YES user_id=521 This patch modifies the behaviour when handling bounce messages with multiple addresses, such as from Postfix. Now messages in which any of the bouncing addresses cannot be automatically handled are forwarded to the administrator. Eventually it might be nice to put a notice in the message explaining the problem -- e.g. user not found, is not a member, etc. This update also makes "digester lucked out" be considered successful processing. ---------------------------------------------------------------------- Comment By: Tim Potter (tpot) Date: 2002-03-25 10:18 Message: Logged In: YES user_id=9949 The scenario where addresses which don't seem to be on the list can be caused by bounces received after the user has been disabled due to the size of the mail queue. It may cause confusion forwarding them to the admin as there is nothing they can do about it except puzzle over why it was received. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=534298&group_i…

1 0

[ mailman-Bugs-1565707 ] Newlist and groups
by SourceForge.net Sept. 26, 2006

Sept. 26, 2006

Bugs item #1565707, was opened at 2006-09-26 14:53 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=1565707&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: command line scripts Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hypnos Software (alexcomps) Assigned to: Nobody/Anonymous (nobody) Summary: Newlist and groups Initial Comment: In function main: if os.getgid() != mm_cfg.MAILMAN_GROUP: os.setgid(gid) it is comparing a string and a number, so it always run os.setgid(gid) Also I think that it would be better if it checks if you belong to the group, because maybe it is not your primary group but it is one of you secondary ones. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1565707&group_…

1 0

[ mailman-Patches-1564527 ] Patch to separate Makefile arch-dep and arch-indep install
by SourceForge.net Sept. 24, 2006

Sept. 24, 2006

Patches item #1564527, was opened at 2006-09-24 15:26 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=1564527&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: configure/install Group: None Status: Open Resolution: None Priority: 5 Submitted By: Thijs Kinkhorst (kink) Assigned to: Nobody/Anonymous (nobody) Summary: Patch to separate Makefile arch-dep and arch-indep install Initial Comment: Hello! When packaging Mailman for Debian, we create different packages for architecture-specific files and architecture-independent ones. For this we need to separate those install steps. Attached patch adds that possibility to the Mailman makefile; it adds two new targets "do-arch-install" and "do-indep-install"; the old "doinstall" remains and calls both new targets. I think this might be useful to others who wish to separate arch-dep and arch-indep files and it doesn't hurt other users. That's why I request this patch to be included into Mailman. regards, Thijs Kinkhorst Debian Developer ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1564527&group_…

1 0

[ mailman-Bugs-1562922 ] "Discard all...Defer" button appears on mod. detail page
by SourceForge.net Sept. 21, 2006

Sept. 21, 2006

Bugs item #1562922, was opened at 2006-09-21 08:05 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1562922&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: Closed >Resolution: Fixed Priority: 5 Submitted By: Dan Astoorian (djast) Assigned to: Nobody/Anonymous (nobody) Summary: "Discard all...Defer" button appears on mod. detail page Initial Comment: This is a clarification and restatement of bug #1000699, which was marked "closed" but describes a bug which is still present. On the admindb pages, there is a checkbox labelled "Discard all messages marked Defer" near each of the submit buttons at the top and bottom of the page. This checkbox appears on the default admindb page (where the requests are grouped by sender), and also on the "?details=all" page (which is reached by following the "You can also view the details of all held postings" link). The checkboxes have no effect on the "?details=all" page (because the form is structured differently from the default admindb page). The comments in Bug #1000699 says that "the 'discard all deferred' checkbox was intended to work only on the summary page. It's appearance on the detail pages was a mistake that was fixed in 2.1.6"; from this I assume that the checkboxes are not supposed to appear on the "?details=all" page, but they're still there. The test in Cgi/admindb.py for whether to supply the button is "if not (sender or msgid):"; perhaps the test should be changed to something like "if not (details or sender or msgid):". (I mentioned this in a comment I attached to closed bug #1000699, but there's been no further discussion, and the bug is still present as of 2.1.9.) ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-09-21 11:28 Message: Logged In: YES user_id=1123998 Your comment on bug # 1000699 slipped through the cracks. I'm sorry. This has now been fixed as you suggest in subversion on both the trunk and the Release_2_1-maint branch. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1562922&group_…

1 0

[ mailman-Bugs-1562922 ] "Discard all...Defer" button appears on mod. detail page
by SourceForge.net Sept. 21, 2006

Sept. 21, 2006

Bugs item #1562922, was opened at 2006-09-21 11:05 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=1562922&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: Dan Astoorian (djast) Assigned to: Nobody/Anonymous (nobody) Summary: "Discard all...Defer" button appears on mod. detail page Initial Comment: This is a clarification and restatement of bug #1000699, which was marked "closed" but describes a bug which is still present. On the admindb pages, there is a checkbox labelled "Discard all messages marked Defer" near each of the submit buttons at the top and bottom of the page. This checkbox appears on the default admindb page (where the requests are grouped by sender), and also on the "?details=all" page (which is reached by following the "You can also view the details of all held postings" link). The checkboxes have no effect on the "?details=all" page (because the form is structured differently from the default admindb page). The comments in Bug #1000699 says that "the 'discard all deferred' checkbox was intended to work only on the summary page. It's appearance on the detail pages was a mistake that was fixed in 2.1.6"; from this I assume that the checkboxes are not supposed to appear on the "?details=all" page, but they're still there. The test in Cgi/admindb.py for whether to supply the button is "if not (sender or msgid):"; perhaps the test should be changed to something like "if not (details or sender or msgid):". (I mentioned this in a comment I attached to closed bug #1000699, but there's been no further discussion, and the bug is still present as of 2.1.9.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1562922&group_…

1 0