Mailman 3 January 2010 - 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

[Bug 514625] [NEW] Mailman 3 member functions should "guess" address membership
by Stephen Turnbull May 23, 2015

May 23, 2015

Public bug reported: Feature request Mailman 3 should try to fuzzily match unknown author addresses against the member database. For example, if "turnbull(a)sk.domain.tld" is subscribed, then "turnbull(a)shako.sk.domain.tld" probably is the same person. This could probably be efficiently implemented by storing domains in bigendian order, and testing for prefixes. Bonus points for matching on full name. For example, for me personally firstname(a)xemacs.org and lastname(a)xemacs.org both resolve to me, which could not be reasonably associated by algorithm, but I always use the same full name, which would be strong indication that it's me. Possibly matching on mailbox would also be useful, but only as an optimization to be confirmed by one of the other two (or maybe if the match is unique?) Note that for the first example, the second "turnbull@shako" variant is today used only by spammers; I haven't sent a message with that "From" since 1995, and I doubt it's been used as "Sender" more than a very small handful of times since 2000. For this reason, the feature should *never* be automated. Instead, it should be part of the moderation interface. If a match is detected, then an option should appear saying something like "This address appears to be an alias for <member name and address>. [ ] Add <unknown address> as an alias for <member>." ** Affects: mailman Importance: Undecided Status: New ** Description changed: Feature request Mailman 3 should try to fuzzily match unknown author addresses against the member database. For example, if "turnbull(a)sk.tsukuba.ac.jp" is subscribed, then "turnbull(a)shako.sk.tsukuba.ac.jp" probably is the same person. This could probably be efficiently implemented by storing domains in bigendian order, and testing for prefixes. Bonus points for matching on full name. For example, for me personally firstname(a)xemacs.org and lastname(a)xemacs.org both resolve to me, which could not be reasonably associated by algorithm, but I always use the same full name, which would be strong indication that it's me. Possibly matching on mailbox would also be useful, but only as an optimization to be confirmed by one of the other two (or maybe if the match is unique?) Note that for the first example, the second "turnbull@shako" variant is today used only by spammers; I haven't sent a message with that "From" since 1995, and I doubt it's been used as "Sender" more than a very small handful of times since 2000. For this reason, the feature should *never* be automated. Instead, it should be part of the moderation interface. If a match is detected, then an option should appear saying something like "This address appears to be an alias for <member name and - address>. [ ] Add <unknown> address as an alias for <member>." + address>. [ ] Add <unknown address> as an alias for <member>." ** Description changed: Feature request Mailman 3 should try to fuzzily match unknown author addresses against - the member database. For example, if "turnbull(a)sk.tsukuba.ac.jp" is - subscribed, then "turnbull(a)shako.sk.tsukuba.ac.jp" probably is the same + the member database. For example, if "turnbull(a)sk.domain.tld" is + subscribed, then "turnbull(a)shako.sk.domain.tld" probably is the same person. This could probably be efficiently implemented by storing domains in bigendian order, and testing for prefixes. Bonus points for matching on full name. For example, for me personally firstname(a)xemacs.org and lastname(a)xemacs.org both resolve to me, which could not be reasonably associated by algorithm, but I always use the same full name, which would be strong indication that it's me. Possibly matching on mailbox would also be useful, but only as an optimization to be confirmed by one of the other two (or maybe if the match is unique?) Note that for the first example, the second "turnbull@shako" variant is today used only by spammers; I haven't sent a message with that "From" since 1995, and I doubt it's been used as "Sender" more than a very small handful of times since 2000. For this reason, the feature should *never* be automated. Instead, it should be part of the moderation interface. If a match is detected, then an option should appear saying something like "This address appears to be an alias for <member name and address>. [ ] Add <unknown address> as an alias for <member>." -- Mailman 3 member functions should "guess" address membership https://bugs.launchpad.net/bugs/514625 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

4 5

[Bug 500955] [NEW] Templates for AST use inconsistent DOCTYPE
by Matt Selsky June 15, 2012

June 15, 2012

Public bug reported: Most of the templates use a DOCTYPE of HTML 4.01 Transitional, but the AST templates use HTML 3.2. The patch updates the DOCTYPES for the AST templates. ** Affects: mailman Importance: Undecided Status: New -- Templates for AST use inconsistent DOCTYPE https://bugs.launchpad.net/bugs/500955 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

2 3

[Bug 500952] [NEW] Extra escape characters in DOCTYPE
by Matt Selsky June 15, 2012

June 15, 2012

Public bug reported: The DOCTYPE header for 2 files in the sk templates contain extra escape characters around the quote marks. ** Affects: mailman Importance: Undecided Status: New -- Extra escape characters in DOCTYPE https://bugs.launchpad.net/bugs/500952 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

2 3

[Bug 501739] [NEW] Approved: header not always removed
by Mark Sapiro Sept. 21, 2010

Sept. 21, 2010

Public bug reported: Approve follows SpamDetect in the default pipeline. If SpamDetect or another custom or reordered handler preceding Approve holds a post containing an Approve(d): header or pseudo-header, and that post is approved, the Approve(d): header or pseudo-header will not be removed from the delivered message. ** Affects: mailman Importance: Undecided Status: New -- Approved: header not always removed https://bugs.launchpad.net/bugs/501739 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 2

[Bug 514050] [NEW] listinfo.html templates have a misplaced form start tag
by Mark Sapiro Sept. 21, 2010

Sept. 21, 2010

Public bug reported: The tag <MM-Subscribe-Form-Start> which generates the <form> tag for the subscribe form is in the <td> entry for the language form. This generates invalid HTML which is a problem for at least some browsers. There is also no DOCTYPE directive and other misplaced tags that cause validation errors. ** Affects: mailman Importance: Undecided Status: New -- listinfo.html templates have a misplaced form start tag https://bugs.launchpad.net/bugs/514050 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 2

[Bug 497968] [NEW] Need a 'no-daemonize' option for '/bin/mailman start'
by Steve Burling June 19, 2010

June 19, 2010

Public bug reported: The version of Mailman distributed with Apple's Mac OS X Server has a hacked up mailmanctl, primarily to support not daemonizing in the launchd environment. (I think). Their hack is ugly, and it'd be nice if it was made unnecessary. ** Affects: mailman Importance: Undecided Status: New -- Need a 'no-daemonize' option for '/bin/mailman start' https://bugs.launchpad.net/bugs/497968 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

2 5

[Bug 515305] [NEW] List password reset while pending messages, they are deleted!
by Maelvon Feb. 1, 2010

Feb. 1, 2010

Public bug reported: I've reseted the admin password with : /usr/lib/mailman/bin/change_pw -l mylist -p mynewpassword While having a pending message. But after the reset, the message seems deleted, cannot find it anymore! So, is that a feature? Can I retrieve the lost message and reapproved it? Maelvon ** Affects: mailman Importance: Undecided Status: New -- List password reset while pending messages, they are deleted! https://bugs.launchpad.net/bugs/515305 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

2 4

[Bug 490114] Re: Mailman should be compliant with the Filesystem Hierarchy Standard
by Launchpad Bug Tracker Jan. 29, 2010

Jan. 29, 2010

** Branch linked: lp:mailman -- Mailman should be compliant with the Filesystem Hierarchy Standard https://bugs.launchpad.net/bugs/490114 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 490114] Re: Mailman should be compliant with the Filesystem Hierarchy Standard
by Barry Warsaw Jan. 29, 2010

Jan. 29, 2010

r6888 ** Changed in: mailman/3.0 Status: Triaged => Fix Committed ** Changed in: mailman/3.0 Assignee: (unassigned) => Barry Warsaw (barry) -- Mailman should be compliant with the Filesystem Hierarchy Standard https://bugs.launchpad.net/bugs/490114 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 490114] Re: Mailman should be compliant with the Filesystem Hierarchy Standard
by Barry Warsaw Jan. 29, 2010

Jan. 29, 2010

** Summary changed: - Mailman should be compliant with the File System Hierarchy + Mailman should be compliant with the Filesystem Hierarchy Standard ** Also affects: mailman/3.0 Importance: High Status: Triaged ** Changed in: mailman/3.0 Milestone: None => 3.0.0a6 -- Mailman should be compliant with the Filesystem Hierarchy Standard https://bugs.launchpad.net/bugs/490114 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 244233] Re: Logrotate is noisy with: Re-opening all log files
by Thierry Carrez Jan. 28, 2010

Jan. 28, 2010

@Petri: I thought I had nominated/approved it. Done now, sorry for the noise. ** Also affects: mailman (Ubuntu Hardy) Importance: Undecided Status: New -- Logrotate is noisy with: Re-opening all log files https://bugs.launchpad.net/bugs/244233 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 244233] Re: Logrotate is noisy with: Re-opening all log files
by Petri Koistinen Jan. 28, 2010

Jan. 28, 2010

It seems that I can't use "Nominate for release" as this has been previously declined for Hardy. ** Changed in: mailman (Ubuntu) Status: Triaged => Fix Released -- Logrotate is noisy with: Re-opening all log files https://bugs.launchpad.net/bugs/244233 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 244233] Re: Logrotate is noisy with: Re-opening all log files
by Thierry Carrez Jan. 28, 2010

Jan. 28, 2010

Approved, please follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure to submit SRU for consideration. ** Changed in: mailman (Ubuntu) Status: Incomplete => Triaged ** Changed in: mailman (Ubuntu) Assignee: Thierry Carrez (ttx) => (unassigned) -- Logrotate is noisy with: Re-opening all log files https://bugs.launchpad.net/bugs/244233 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 244233] Re: Logrotate is noisy with: Re-opening all log files
by Petri Koistinen Jan. 28, 2010

Jan. 28, 2010

I think this fits just fine to this definition: * Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel). ** Changed in: mailman (Ubuntu) Status: Fix Released => Incomplete ** Changed in: mailman (Ubuntu) Assignee: (unassigned) => Thierry Carrez (ttx) -- Logrotate is noisy with: Re-opening all log files https://bugs.launchpad.net/bugs/244233 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 244233] Re: Logrotate is noisy with: Re-opening all log files
by Thierry Carrez Jan. 27, 2010

Jan. 27, 2010

Bug is fix released in the current development version. Bug was rejected for hardy SRU since stable release updates are here to address "high-impact" bugs, and during review this was not considered to be high-impact. See https://wiki.ubuntu.com/StableReleaseUpdates#When ** Changed in: mailman (Ubuntu) Status: Incomplete => Fix Released ** Changed in: mailman (Ubuntu) Assignee: Thierry Carrez (ttx) => (unassigned) -- Logrotate is noisy with: Re-opening all log files https://bugs.launchpad.net/bugs/244233 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 244233] Re: Logrotate is noisy with: Re-opening all log files
by Petri Koistinen Jan. 27, 2010

Jan. 27, 2010

Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456954 ** Bug watch added: Debian Bug tracker #456954 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456954 ** Changed in: mailman (Ubuntu) Status: Fix Released => Incomplete ** Changed in: mailman (Ubuntu) Assignee: (unassigned) => Thierry Carrez (ttx) -- Logrotate is noisy with: Re-opening all log files https://bugs.launchpad.net/bugs/244233 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 244233] Re: Logrotate is noisy with: Re-opening all log files
by Petri Koistinen Jan. 27, 2010

Jan. 27, 2010

What does this "Declined for Hardy by Thierry Carrez" means, what is the reasoning behind declining this update to hardy (8.04 LTS) release? -- Logrotate is noisy with: Re-opening all log files https://bugs.launchpad.net/bugs/244233 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 266164] Re: Private archive specific message URL lost in authorization
by Mark Sapiro Jan. 22, 2010

Jan. 22, 2010

The original fix released in Mailman 2.1.7 was incomplete. It didn't properly account for http://www.example.com/mailman/private/list- name.mbox/listname.mbox URLs. This oversight has been corrected and committed on the 2.1 branch at rev 1217. ** Changed in: mailman Importance: Medium => Low ** Changed in: mailman Status: Fix Released => Fix Committed ** Changed in: mailman Assignee: (unassigned) => Mark Sapiro (msapiro) ** Branch linked: lp:mailman/2.1 ** Branch linked: lp:mailman/2.2 -- Private archive specific message URL lost in authorization https://bugs.launchpad.net/bugs/266164 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 507841] [NEW] show list moderators on listinfo page too
by Daniel Holbach Jan. 15, 2010

Jan. 15, 2010

Public bug reported: It would be nice if the listinfo page wouldn't just show "list is run by X, Y and Z" but also who's moderating it. For a big project this would help to find lists with inactive moderators and admins, but also increase the transparency of the project. As far as I can see this would need to be fixed in Mailman/HTMLFormatter.py. ** Affects: mailman Importance: Undecided Status: New -- show list moderators on listinfo page too https://bugs.launchpad.net/bugs/507841 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 266760] Re: moderation approval should send email notification
by Raphaël Barrois Jan. 7, 2010

Jan. 7, 2010

--- Acknowledge.py.orig 2010-01-07 15:50:01.000000000 +0100 +++ Acknowledge.py 2010-01-07 15:50:43.000000000 +0100 @@ -38,7 +38,8 @@ if not ack: return except Errors.NotAMemberError: - return + if not mlist.notify_nonmembers_post_approved: + return # Okay, they want acknowledgement of their post. Give them their original # subject. BAW: do we want to use the decoded header? origsubj = msgdata.get('origsubj', msg.get('subject', _('(no subject)'))) -- moderation approval should send email notification https://bugs.launchpad.net/bugs/266760 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 266760] Re: moderation approval should send email notification
by Raphaël Barrois Jan. 7, 2010

Jan. 7, 2010

I think this functionnality would be quite useful for mailing lists used with "non-tech" users, who don't understand why they aren't notified of their message being approved... -- moderation approval should send email notification https://bugs.launchpad.net/bugs/266760 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 265965] Re: url parse (probably) cannot handle port number
by Mark Sapiro Jan. 7, 2010

Jan. 7, 2010

The original bug is invalid. If the site is properly configured with the appropriate port in DEFAULT_URL_PATTERN and PUBLIC_ARCHIVE_URL in mm_cfg.py the web interface works fine. E.g. DEFAULT_URL_PATTERN = 'http://%s:8080/mailman PUBLIC_ARCHIVE_URL = 'http://%(hostname)s:8080/pipermail/%(listname)s' After making such a change in mm_cfg.py, you need to run fix_url to update existing lists. See the FAQs at <http://wiki.list.org/x/gIA9> and <http://wiki.list.org/x/mIA9>. The issue in the comment from Raphael Mankin is probably because the list's host_name attribute has a port. It should not. This in turn probably results from having a port appended to DEFAULT_EMAIL_HOST or the host in an add_virtualhost() directive. This is a misconfiguration. Note that the list's host_name is exposed and can be changed on the list's General Options admin page. ** Changed in: mailman Status: New => Invalid -- url parse (probably) cannot handle port number https://bugs.launchpad.net/bugs/265965 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 265965] Re: url parse (probably) cannot handle port number
by Raphael Mankin Jan. 6, 2010

Jan. 6, 2010

In particular, all mails sent from mailman have the port number on the end of the reply address. This causes certain mail servers to reject the messagges. A workaround is to have two web listeners, one on port 80 and one on the real port e.g. 8080. One then redirects all mailman requests on port 80 to the other port. I do this because I have to have my main web server and my mailman web server running as different users. The problem is current in 2.1.12 -- url parse (probably) cannot handle port number https://bugs.launchpad.net/bugs/265965 You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman.

1 0

[Bug 490602] Re: sourcecode/mailman/configure.in does not support group names with spaces
by Barry Warsaw Jan. 6, 2010

Jan. 6, 2010

This is not worth fixing. Mailman 3 doesn't use the same mechanism, and in all the years of MM2 development, this is the first such complaint about this I've seen. I didn't even know spaces in group names on *nix was allowed <wink>. ** Changed in: mailman Status: Confirmed => Won't Fix -- sourcecode/mailman/configure.in does not support group names with spaces https://bugs.launchpad.net/bugs/490602 You received this bug notification because you are a member of Mailman Coders, which is a direct subscriber.

1 0