Mailman-coders November 2005

mailman-coders@python.org

1 participants
52 discussions

[ mailman-Bugs-1263213 ] checkbox "Send list created" not saved if failure
by SourceForge.net 09 Nov '05

09 Nov '05

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

1 0

[ mailman-Feature Requests-1269067 ] e-mail command confirmations should be optional
by SourceForge.net 09 Nov '05

09 Nov '05

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

1 0

[ mailman-Feature Requests-1269025 ] unsubscribe removal confirmation should be optional
by SourceForge.net 09 Nov '05

09 Nov '05

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

1 0

[ mailman-Bugs-1268939 ] host_name tag doesn't allow IP addresses
by SourceForge.net 09 Nov '05

09 Nov '05

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

1 0

[ mailman-Bugs-1263213 ] checkbox "Send list created" not saved if failure
by SourceForge.net 09 Nov '05

09 Nov '05

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

1 0

[ mailman-Feature Requests-1269067 ] e-mail command confirmations should be optional
by SourceForge.net 09 Nov '05

09 Nov '05

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

1 0

[ mailman-Feature Requests-1269025 ] unsubscribe removal confirmation should be optional
by SourceForge.net 09 Nov '05

09 Nov '05

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

1 0

[ mailman-Bugs-1268939 ] host_name tag doesn't allow IP addresses
by SourceForge.net 09 Nov '05

09 Nov '05

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

1 0

[ mailman-Bugs-1263219 ] Link of the 'admin' page not updated if config change
by SourceForge.net 07 Nov '05

07 Nov '05

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

1 0

[ mailman-Bugs-1263219 ] Link of the 'admin' page not updated if config change
by SourceForge.net 07 Nov '05

07 Nov '05

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

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