Patches item #1727084, was opened at 2007-05-28 22:48
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=1727084&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: Mailman 2.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Alexis (alexistr)
Assigned to: Nobody/Anonymous (nobody)
Summary: invite_members command line
Initial Comment:
A script to invite new members from command line.
Derived from add_members.
I add "-l" option to choose the language of the invited user.
To have de mail sent in the proper language small change are necessary in MailList.py function InviteNewMember:
if userdesc.language:
lang = userdesc.language
else:
lang = self.preferred_language
-----------------
Utils.maketext(.............lang=lang)
-----------------
Message.UserNotification(...............lang=lang)
Could be nice to add this as an option in add_members.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1727084&group_…
Feature Requests item #1726694, was opened at 2007-05-27 20:27
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=1726694&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
Private: No
Submitted By: EricB (eric_black)
Assigned to: Nobody/Anonymous (nobody)
Summary: Need to limit repeated subscribes from bot
Initial Comment:
It's happened, some kiddie with a bot/script has decided it would be fun to attack hir favorite target by sending hundreds of subscribe messages to our mailman server. Each one causes a confirmation email to be sent to the victim. Needless to say, they are not pleased, and consider our repeated automatic confirmation emails to be spam.
Mailman should keep track of the number of subscribe requests for an email address and ignore any past a configurable number within some configurable period of time. For example, up to 2 within 24 hours is OK but beyond that is silently ignored.
This could be related to other feature requests to limit the number of subscribe requests from a single source IP.
Is this already available and I just can't find it?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1726694&group_…
Feature Requests item #1723015, was opened at 2007-05-21 15:34
Message generated for change (Comment added) made by migopod
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1723015&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
Private: No
Submitted By: migopod (migopod)
Assigned to: Nobody/Anonymous (nobody)
Summary: Admin notify schedule
Initial Comment:
One of our site users has suggested that it would be
useful for her to be able to schedule moderator notification emails at intervals besides daily and immediate.
She would prefer the option of being able to get a weekly moderator notification rather than daily.
Since this is one user out of over 5000 on our system, and since i would presume the vast majority of users would rather get more frequent notifications, i would think this a low priority, but i told them i'd submit a feature request for it, and i try to be an admin of my word.
Thanks
----------------------------------------------------------------------
>Comment By: migopod (migopod)
Date: 2007-05-21 16:49
Message:
Logged In: YES
user_id=1798406
Originator: YES
This is the case. The vast majority of our users are happy with daily or
immediate notifications, but one user is requesting the differing
frequency. I'm thinking that we could tweak the cron script and the list
object to
maybe add mlist.admin_notify_frequency and handle it accordingly, but
we've gone to some lengths to not
overly customize the Mailman we're running (custom front-end, vanilla back
end kind of thing).
I can't honestly see this being useful for anything but very low priority
lists, and in a couple of years of providing
the system to thousands of users we've only had this come up once, so
really no pressure. I've already passed it back down through the
escalation chain that she can filter her list-bounces and use our
calendaring software to
send her a weekly reminder to check the moderator queue or deal with the
daily notification.
Thanks for the quick responses!
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2007-05-21 16:26
Message:
Logged In: YES
user_id=1123998
Originator: NO
Jim's suggestion below will not work. digest_volume_frequency only
controls how often the digest's Volume number is incremented, not how often
the digest is sent. The periodic digest will still be sent at intervals
determined by the running of cron/senddigests.
If you wanted to send ALL moderator request summaries at some interval
other than daily, you could adjust the schedule of cron/checkdbs. I assume
however that this request is for moderator request summaries to be sent at
a per-list configurable interval.
----------------------------------------------------------------------
Comment By: Jim Popovitch (jimpop)
Date: 2007-05-21 15:41
Message:
Logged In: YES
user_id=3142
Originator: NO
This is easy to achieve with existing Mailman versions. Just create a
new list for moderation notifications and in digest mode set
digest_volume_frequency to weekly and send_digest_now to yes. Moderators
can choose to subscribe to the digested or the normal immediate
notifications.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1723015&group_…
Feature Requests item #1723015, was opened at 2007-05-21 13:34
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1723015&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
Private: No
Submitted By: migopod (migopod)
Assigned to: Nobody/Anonymous (nobody)
Summary: Admin notify schedule
Initial Comment:
One of our site users has suggested that it would be
useful for her to be able to schedule moderator notification emails at intervals besides daily and immediate.
She would prefer the option of being able to get a weekly moderator notification rather than daily.
Since this is one user out of over 5000 on our system, and since i would presume the vast majority of users would rather get more frequent notifications, i would think this a low priority, but i told them i'd submit a feature request for it, and i try to be an admin of my word.
Thanks
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2007-05-21 14:26
Message:
Logged In: YES
user_id=1123998
Originator: NO
Jim's suggestion below will not work. digest_volume_frequency only
controls how often the digest's Volume number is incremented, not how often
the digest is sent. The periodic digest will still be sent at intervals
determined by the running of cron/senddigests.
If you wanted to send ALL moderator request summaries at some interval
other than daily, you could adjust the schedule of cron/checkdbs. I assume
however that this request is for moderator request summaries to be sent at
a per-list configurable interval.
----------------------------------------------------------------------
Comment By: Jim Popovitch (jimpop)
Date: 2007-05-21 13:41
Message:
Logged In: YES
user_id=3142
Originator: NO
This is easy to achieve with existing Mailman versions. Just create a
new list for moderation notifications and in digest mode set
digest_volume_frequency to weekly and send_digest_now to yes. Moderators
can choose to subscribe to the digested or the normal immediate
notifications.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1723015&group_…
Feature Requests item #1723015, was opened at 2007-05-21 16:34
Message generated for change (Comment added) made by jimpop
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1723015&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
Private: No
Submitted By: migopod (migopod)
Assigned to: Nobody/Anonymous (nobody)
Summary: Admin notify schedule
Initial Comment:
One of our site users has suggested that it would be
useful for her to be able to schedule moderator notification emails at intervals besides daily and immediate.
She would prefer the option of being able to get a weekly moderator notification rather than daily.
Since this is one user out of over 5000 on our system, and since i would presume the vast majority of users would rather get more frequent notifications, i would think this a low priority, but i told them i'd submit a feature request for it, and i try to be an admin of my word.
Thanks
----------------------------------------------------------------------
Comment By: Jim Popovitch (jimpop)
Date: 2007-05-21 16:41
Message:
Logged In: YES
user_id=3142
Originator: NO
This is easy to achieve with existing Mailman versions. Just create a
new list for moderation notifications and in digest mode set
digest_volume_frequency to weekly and send_digest_now to yes. Moderators
can choose to subscribe to the digested or the normal immediate
notifications.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1723015&group_…
Feature Requests item #1723015, was opened at 2007-05-21 15:34
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=1723015&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
Private: No
Submitted By: migopod (migopod)
Assigned to: Nobody/Anonymous (nobody)
Summary: Admin notify schedule
Initial Comment:
One of our site users has suggested that it would be
useful for her to be able to schedule moderator notification emails at intervals besides daily and immediate.
She would prefer the option of being able to get a weekly moderator notification rather than daily.
Since this is one user out of over 5000 on our system, and since i would presume the vast majority of users would rather get more frequent notifications, i would think this a low priority, but i told them i'd submit a feature request for it, and i try to be an admin of my word.
Thanks
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1723015&group_…
Patches item #1719017, was opened at 2007-05-15 03:15
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=1719017&group_…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: internationalization
Group: Mailman 2.1
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Robert S. (rj667)
Assigned to: Nobody/Anonymous (nobody)
Summary: % -> %% fix in templates/nl/private.html
Initial Comment:
The file templates/nl/private.html has WIDTH="100%" instead of WIDTH="100%%", resulting in an incorrect webpage after Mailman processed the template.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1719017&group_…
Bugs item #1598087, was opened at 2006-11-16 15:55
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1598087&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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Tokio Kikuchi (tkikuchi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error mail may be accumulated in qfiles
Initial Comment:
Mailman/Queue/Runner.py is called by other runners and resposible for dequeueing from one queue and enqueue into another after processing. In _oneloop() function it shunts error messages during processing but leaves them in the original queue directory by noting 'Ignoring ...' message in the error log. These left errorneous messages are never treated again and may be accumulated and slow down the queue processing. These messages should be shunted also.
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2007-05-14 11:04
Message:
Logged In: YES
user_id=1123998
Originator: NO
This has now been fixed in SVN (r8204) for Mailman 2.1.10. The fix is
different from both of the attached patches. The original queue entry will
be moved to the shunt queue with a .psv extension and this fact will be
logged.
The end result is the parse error will be logged and the queue entry will
be moved out of the original queue so it won't further impact processing.
The queue entry will be preserved for analysis in the shunt queue, but with
a .psv filename extension so it won't be processed by bin/unshunt.
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2006-11-16 21:36
Message:
Logged In: YES
user_id=1123998
Originator: NO
If I understand the issue correctly, the problem is that the .bak file is
left in the original queue after the parse error. This is not a recoverable
error as explained in the code comment, thus I don't think the proper
action is to shunt the message. Rather, I think the proper action is to
continue to log the event and just remove the .bak file. Not removing the
.bak file was an oversight in the original backup implementation.
My suggested patch is attached.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1598087&group_…
Patches item #1415956, was opened at 2006-01-26 22:23
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1415956&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
Private: No
Submitted By: Bryan Carbonnell (carbonnb)
Assigned to: Nobody/Anonymous (nobody)
Summary: Sitewide headers/footers & XHTML Compliant Web UI
Initial Comment:
This patch was borne out of a request I received to
make the Mailman UI fit the look of the web site. This
patch allows you to set a site wide header and footer.
This allows you to pretty much make the MM UI look like
any other site. While I was at it I also made the web
UI XHTML compliant.
Once you patch your source and install it, all you need
to do is edit the html files in the templates/en
directory. Most of the pages will get the header and
footers from the site-header.html and site-footer.html
files, but some of the HTML files already contain theor
own header/footer so you will need ot edit some of
these files as well.
Since this also adds XHTML compliance, this superceeds
patch #116035
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2007-05-05 21:08
Message:
Logged In: YES
user_id=11375
Originator: NO
A branch for CSS work has been created, modernize_21_webui.
I've committed most of this patch.
The patch to the following files didn't apply: templates/en/roster.html
templates/en/subscribe.html templates/en/listinfo.html
templates/en/admindbdetails.html .
There have been changes to the files since the patch was made, so they'll
basically have to be re-done from scratch. Bryan, do you remember all the
various changes you made, or should I try to disentangle the original and
patched versions?
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2007-05-03 20:52
Message:
Logged In: YES
user_id=11375
Originator: NO
The patch looks pretty good, though I'll suggest some refinements and some
decisions need to be made.
Net effects of the patch:
Adds XHTML compliance.
Adds site-header.html/site-footer.html to the templates/en directory
and usage of CSS instead of <font> tags.
Still uses tables for page layout.
Adds CSS_FILE to mm_cfg.py.
Requires addition of a /css/ directory to the web tree.
Possible issues:
Many I18N strings change, but only by folding HTML markup to lowercase.
A bunch of search-and-replacing should be able to update all the
language-specific templates.
Need to decide upon class naming scheme; the scheme used isn't
consistent (mm_web_adminitem_color in one case, mmErrorBackground
in another).
Could retarget it to use the <div id="mailman"> suggestion
and '#mailman error' selectors.
Possible bug: AddSpanStyle, AddDivStyle: won't generate <div>,<span>
if no 'css_class' is provided. Presumably all current callers get this
right; should the class work properly if there's an error, though?
Compatibility issues:
The patch removes the colour settings (WEB_HEADER_COLOR,
WEB_ERROR_COLOR, WEB_ADMINITEM_COLOR, etc.) -- how to handle backward
compatibility? That would require substituting into the .css file, or
adding a 'style' attribute.
WEB_HEADER_COLOR -- mmHeader
WEB_ERROR_COLOR -- replaced by mmErrorBackground CSS class
WEB_ADMINITEM_COLOR -- replaced by mmRight/mmLeft/mm_web_adminitem_color/
mmAdminItem
Features not present that I thought of:
* allow adding an embedded stylesheet
* allow adding JavaScript links or text to the <head>
* adding an onLoad to the body (perhaps not necessary -- can it be done in
a <script> tag using DOM Events?)
----------------------------------------------------------------------
Comment By: Bryan Carbonnell (carbonnb)
Date: 2006-01-28 23:07
Message:
Logged In: YES
user_id=449953
Updated both patches to remove some of my site specific HTML
coding.
----------------------------------------------------------------------
Comment By: Bryan Carbonnell (carbonnb)
Date: 2006-01-26 22:31
Message:
Logged In: YES
user_id=449953
I am also uploading a second version of this patch. This
second version will add the sitewide headers/footer to
source that has been patched with the ht://dig integration
patches.
At the time I posted this, the official ht://dig integration
patches were not released, but the MM2.1.6 patches appear to
work with MM 2.1.7, so they are what were used.
to apply this patch use this command from your mailman
source directory:
patch -p1 <full/path/to/headfoot-htdig-2.1.7-0.1.patch
----------------------------------------------------------------------
Comment By: Bryan Carbonnell (carbonnb)
Date: 2006-01-26 22:27
Message:
Logged In: YES
user_id=449953
I have only tested this with the english pages. I'm not sure
how to deal with i18n yet, but I'm reading and I will update
this patch as soon as I figure out how to deal with it.
To apply this patch for MM2.1.7, you will need to apply
patch #1405790 (Mailman 2.1.7 multiple patch) first.
to apply this patch use this command from your mailman
source directory:
patch -p1 <full/path/to/headfoot-2.1.7-0.1.patch
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1415956&group_…
Bugs item #1712034, was opened at 2007-05-03 07:39
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1712034&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: Pipermail
Group: 2.1 (stable)
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Stephen J. Turnbull (yaseppochi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Pipermail uses MIME CTEs in HTTP
Initial Comment:
CTE = Content-Transfer-Encoding = BASE64 or QP
John Papapanos writes:
> Here is a URL where I created a list for testing
> mailman.
>
> https://mail.bioacademy.gr/pipermail/testlist2/2007-May/thread.html
Wow! That's amazingly broken. What's I'm pretty sure is happening is that the archive contains raw message content in a MIME QP or transfer-encoding, which cannot be decoded because the Content-Transfer-Encoding header has been stripped (AFAIK it's actually prohibited in HTTP, cf RFC 2616 section 19.5). (I'm not 100% sure because I don't have access to the physical archive, only via https.)
The reason that the Greek text-only comes out OK is that your browser (John and I are both using Firefox) interprets the { notation in the message body as SGML entities, which are Unicode.
Presumably the reason that such content is in there in the first place is that either pipermail doesn't parse the mail (unlikely) or it reencodes use flatten or something like that.
I'll look more carefully at the code later, maybe provide a patch, but don't bet on it.
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2007-05-04 13:36
Message:
Logged In: YES
user_id=1123998
Originator: NO
It turns out that John was using Mailman 2.1.5. When he upgraded to 2.1.9,
these problems disappeared. See
<http://mail.python.org/pipermail/mailman-users/2007-May/056942.html>
I'm not certain, but I think this issue was fixed by changes in SVN rev.
7660 of Scrubber.py (Mailman 2.1.7).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1712034&group_…