Feature Requests item #824944, was opened at 2003-10-16 11:35
Message generated for change (Comment added) made by mainecoder
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=824944&group_i…
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex (halloalex)
Assigned to: Nobody/Anonymous (nobody)
Summary: Yahoogroups
Initial Comment:
Hi,
I consider to install Mailman on my server to host several
communities. But unfortunately up till now Mailman is
only designed for mailing lists. So it doesnt offer the
possibility to upload files, etc. To be honest, I also think
that the design of Yahoogroups is more userfriendly. Has
anybody ever thought about to enhance Mailman, so
that it can compete with Yahoogroups?
Greetings from Alex,
who appreciates every hint in this direction
----------------------------------------------------------------------
Comment By: Joe (mainecoder)
Date: 2003-12-31 12:11
Message:
Logged In: YES
user_id=941049
Competition for YahooGroups should be a priority. There are
a number of applications that currently exist and can be
combined to produce a similar product. The weak link
however is a userfriendly Web interface. Create a Web look
and feel like Snitz Forums with the power of Mailman... this is
the first step to building a true alternative for YahooGroups.
----------------------------------------------------------------------
Comment By: Alex (halloalex)
Date: 2003-10-17 12:51
Message:
Logged In: YES
user_id=767295
Well, unfortunately I am just a poor student with basic
computer knowledge and all of my websites are non-profit-
projects. So I guess I am not really helpful for you. However,
if anyone develops something like Yahoogroups or maybe
knows a company that already offers such a script, please
inform me. For a stable version I would not even hesitate to
pay - lets say- up to 350 to 400 US.
Regards,
alex
----------------------------------------------------------------------
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-10-16 13:16
Message:
Logged In: YES
user_id=12800
Sure. Introduce me to the VC with money burning holes in
his pockets and I think we could do something killer. :)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=824944&group_i…
Bugs item #660733, was opened at 2003-01-01 18:29
Message generated for change (Comment added) made by followme
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=660733&group_i…
Category: Pipermail
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 7
Submitted By: Bryan Fullerton (fehwalker)
Assigned to: Nobody/Anonymous (nobody)
Summary: pipermail date handling
Initial Comment:
I moved my first list to mailman 2.1 and tried to re-generate the pipermail archives (just, ya know, to see how it'd work :), and got the following traceback. This is a list that's been around for a long time (archives back to 1995), and the .mbox file was generated from a majordomo/hypermail archive when it was moved to mailman 2.0 a couple of years ago.
Here's a ls -l of the .mbox file:
-rw-rw-r-- 1 mailman mailman 17741891 Jan 1 10:36 bryans-list.mbox
Here's the traceback:
Updating HTML for article 467
Updating HTML for article 468
Updating HTML for article 469
Updating HTML for article 473
Updating HTML for article 472
Pickling archive state into /home/mailman-2.1/archives/private/bryans-list/pipermail.pck
Traceback (most recent call last):
File "bin/arch", line 187, in ?
main()
File "bin/arch", line 175, in main
archiver.processUnixMailbox(fp, start, end)
File "/home/mailman-2.1/Mailman/Archiver/pipermail.py", line 544, in processUnixMailbox
m = mbox.next()
File "/usr/local/lib/python2.2/mailbox.py", line 34, in next
return self.factory(_Subfile(self.fp, start, stop))
File "/home/mailman-2.1/Mailman/Mailbox.py", line 79, in scrubber
return mailbox.scrub(msg)
File "/home/mailman-2.1/Mailman/Mailbox.py", line 99, in scrub
return self._scrubber(self._mlist, msg)
File "/home/mailman-2.1/Mailman/Handlers/Scrubber.py", line 132, in process
dir = calculate_attachments_dir(mlist, msg, msgdata)
File "/home/mailman-2.1/Mailman/Handlers/Scrubber.py", line 93, in calculate_attachments_dir
datedir = safe_strftime(fmt, now)
File "/home/mailman-2.1/Mailman/Handlers/Scrubber.py", line 77, in safe_strftime
return time.strftime(fmt, floatsecs)
TypeError: argument must be 9-item sequence, not None
I'm guessing it's a header problem in one of the messages, but I'm not sure what.
Thanks,
Bryan
----------------------------------------------------------------------
Comment By: Zoran Dzelajlija (followme)
Date: 2003-12-31 16:31
Message:
Logged In: YES
user_id=106281
I can confirm this with 2.1.2. Is there a simple way to make arch guess dates
better?
I would settle for arch using the date of the previous message, but I don't
know wher to start digging in the code.
----------------------------------------------------------------------
Comment By: Bryan Fullerton (fehwalker)
Date: 2003-01-01 19:45
Message:
Logged In: YES
user_id=660772
After some investigation, the following (admittedly invalid) date headers cause tracebacks similar to the above. After reformatting them I'm able to generate the archive.
Date: 25 Aug 95 18.00
Date: Thursday, 30 October 1997 3:02pm PT
Date: Mon, 29 Nov 1999 Pacific Standard Time
Note that these messages *didn't* cause bin/arch|pipermail in mailman 2.0.x to fail, though it probably didn't parse them properly. Perhaps trapping the error and/or skipping these messages might be more useful?
It also appears that bin/arch is throwing all messages with dates it can't figure out (after the above were removed) into the current day. An example can be seen at http://lists.samurai.com/pipermail/bryans-list/2003-January/thread.html . I'm unsure if there's any way to better handle this, but just wanted to note it - I can create a separate bug report if it's important.
Thanks,
Bryan
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=660733&group_i…
Bugs item #776850, was opened at 2003-07-24 12:09
Message generated for change (Settings changed) made by pheinlein
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=776850&group_i…
Category: Web/CGI
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Jan Kellermann (werk21)
Assigned to: Peer Heinlein (pheinlein)
Summary: German version: confusing interface
Initial Comment:
In the membership area are two submit buttons:
"Submit your Changes" and "set". The 2nd on is to set
everyone's moderation bit.
In the german version they are "Änderungen vornehmen"
and "Änderung übernehmen" which is too similar, leading
users to wrongly submit.
Please change this in the language-module.
thx Jan Kellermann
----------------------------------------------------------------------
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-12-28 23:50
Message:
Logged In: YES
user_id=12800
Peer, is this bug still valid? If not, please close this
bug report.
----------------------------------------------------------------------
Comment By: Jan Kellermann (werk21)
Date: 2003-07-24 12:13
Message:
Logged In: YES
user_id=737219
BTW you can please change
"Membership Management" in "Mitgliederverwaltung"
and "Privacy Options" in "Sicherheitseinstellungen"
as used in older versions. :)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=776850&group_i…
Bugs item #863989, was opened at 2003-12-21 16:49
Message generated for change (Comment added) made by m-a
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=863989&group_i…
Category: bounce detection
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Andree (m-a)
Assigned to: Nobody/Anonymous (nobody)
Summary: Postfix delayed notification not recognized.
Initial Comment:
Hi,
I am running Mailman 2.1.3 (stable) with Postfix 2.0.16-20031022.
It seems to be running fine with the VERP patch (it is comfortably
surprising to see how much Mailman has matured since the
unusable 1.1 version - I hated 1.1 but I do like 2.1! You've done
wonderful work.)
However I have one problem that I cannot resolve myself:
Mailman apparently does not parse Postfix' delayed notification
which is apparently RFC-1894 conformant (Postfix hasn't been
updated to RFC-3464 yet).
On superficial inspection, it looks as though Mailman's
Bouncers/DSN.py should handle it and return "Stop", as but I'm
getting this "uncaught bounce" message which I interpret as
"haven't figured anything reasonable from this bounce".
The unintelligible bounce is attached and has had mail addresses
changed (sed) and the delayed mail header removed for privacy
reasons. I can provide the full message to a developer on request,
but I cat not put it into a public bug tracker.
The MIME structure of Postfix' delay notification is:
1 multipart/report
1.1 text/plain
1.2 message/delivery-status
1.3 text/rfc822-headers
The message/delivery-status part has "Action: delayed" in the 2nd
header block. See for yourself.
Am I misunderstanding Mailman
or is Mailman misunderstanding Postfix?
Thanks in advance.
----------------------------------------------------------------------
>Comment By: Matthias Andree (m-a)
Date: 2003-12-29 04:40
Message:
Logged In: YES
user_id=2788
Urgh. Did I say I have these narrow edit forms and line
breaking behind my back without preview? Please apologize
the awful formatting.
----------------------------------------------------------------------
Comment By: Matthias Andree (m-a)
Date: 2003-12-29 04:38
Message:
Logged In: YES
user_id=2788
Hum, looks like this issue isn't Postfix specific, but
affects all
systems that send a delay notification.
"logs/bounce" contains:
Dec 27 20:35:45 2003 (2053) bounce message w/no discernable
addresses: <mumble>
Dec 27 20:35:45 2003 (2053) forwarding unrecognized,
message-id: <mumble>
If I save exactly this mail (I checked the Message-ID) and
feed it to
onebounce.py, I'm getting "DSN got Stop", so that part is fine.
I've dug a bit deeper, and noticed a difference between
onebounce.py and
BouncerAPI.ScanMessages. See lines 65ff in BouncerAPI.py:
addrs = sys.modules[modname].process(msg)
if addrs is Stop:
# One of the detectors recognized the bounce,
but there were no
# addresses to extract. Return the empty list.
return []
I wonder if ScanMessages() is doing the right thing, mapping
Stop to [].
Evidently, the BounceRunner assumes [] is a parse failure
(no addresses
returned) and ultimately forwards the "delay notification"
to the admin
contrary to original DSN.py "Stop" intent. To me, it seems
as though
ScanMessages needed a fix that allows it to propagate both
states,
"bounce recognized, no addresses" and "bounce unrecognized",
back to its
caller.
I wonder if the "Stop" condition should be exposed to the
BounceRunner
or some other interface extension in ScanMessages.
What do you think?
----------------------------------------------------------------------
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-12-27 07:50
Message:
Logged In: YES
user_id=12800
Hmm, I get Stop when I run this message through the DSN.py
bounce processor, so as near as I can tell, this is working
properly.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=863989&group_i…
Bugs item #863989, was opened at 2003-12-21 16:49
Message generated for change (Comment added) made by m-a
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=863989&group_i…
Category: bounce detection
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Andree (m-a)
Assigned to: Nobody/Anonymous (nobody)
Summary: Postfix delayed notification not recognized.
Initial Comment:
Hi,
I am running Mailman 2.1.3 (stable) with Postfix 2.0.16-20031022.
It seems to be running fine with the VERP patch (it is comfortably
surprising to see how much Mailman has matured since the
unusable 1.1 version - I hated 1.1 but I do like 2.1! You've done
wonderful work.)
However I have one problem that I cannot resolve myself:
Mailman apparently does not parse Postfix' delayed notification
which is apparently RFC-1894 conformant (Postfix hasn't been
updated to RFC-3464 yet).
On superficial inspection, it looks as though Mailman's
Bouncers/DSN.py should handle it and return "Stop", as but I'm
getting this "uncaught bounce" message which I interpret as
"haven't figured anything reasonable from this bounce".
The unintelligible bounce is attached and has had mail addresses
changed (sed) and the delayed mail header removed for privacy
reasons. I can provide the full message to a developer on request,
but I cat not put it into a public bug tracker.
The MIME structure of Postfix' delay notification is:
1 multipart/report
1.1 text/plain
1.2 message/delivery-status
1.3 text/rfc822-headers
The message/delivery-status part has "Action: delayed" in the 2nd
header block. See for yourself.
Am I misunderstanding Mailman
or is Mailman misunderstanding Postfix?
Thanks in advance.
----------------------------------------------------------------------
>Comment By: Matthias Andree (m-a)
Date: 2003-12-29 04:38
Message:
Logged In: YES
user_id=2788
Hum, looks like this issue isn't Postfix specific, but
affects all
systems that send a delay notification.
"logs/bounce" contains:
Dec 27 20:35:45 2003 (2053) bounce message w/no discernable
addresses: <mumble>
Dec 27 20:35:45 2003 (2053) forwarding unrecognized,
message-id: <mumble>
If I save exactly this mail (I checked the Message-ID) and
feed it to
onebounce.py, I'm getting "DSN got Stop", so that part is fine.
I've dug a bit deeper, and noticed a difference between
onebounce.py and
BouncerAPI.ScanMessages. See lines 65ff in BouncerAPI.py:
addrs = sys.modules[modname].process(msg)
if addrs is Stop:
# One of the detectors recognized the bounce,
but there were no
# addresses to extract. Return the empty list.
return []
I wonder if ScanMessages() is doing the right thing, mapping
Stop to [].
Evidently, the BounceRunner assumes [] is a parse failure
(no addresses
returned) and ultimately forwards the "delay notification"
to the admin
contrary to original DSN.py "Stop" intent. To me, it seems
as though
ScanMessages needed a fix that allows it to propagate both
states,
"bounce recognized, no addresses" and "bounce unrecognized",
back to its
caller.
I wonder if the "Stop" condition should be exposed to the
BounceRunner
or some other interface extension in ScanMessages.
What do you think?
----------------------------------------------------------------------
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-12-27 07:50
Message:
Logged In: YES
user_id=12800
Hmm, I get Stop when I run this message through the DSN.py
bounce processor, so as near as I can tell, this is working
properly.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=863989&group_i…
Bugs item #776850, was opened at 2003-07-24 06:09
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=776850&group_i…
Category: Web/CGI
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jan Kellermann (werk21)
Assigned to: Peer Heinlein (pheinlein)
Summary: German version: confusing interface
Initial Comment:
In the membership area are two submit buttons:
"Submit your Changes" and "set". The 2nd on is to set
everyone's moderation bit.
In the german version they are "Änderungen vornehmen"
and "Änderung übernehmen" which is too similar, leading
users to wrongly submit.
Please change this in the language-module.
thx Jan Kellermann
----------------------------------------------------------------------
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-12-28 17:50
Message:
Logged In: YES
user_id=12800
Peer, is this bug still valid? If not, please close this
bug report.
----------------------------------------------------------------------
Comment By: Jan Kellermann (werk21)
Date: 2003-07-24 06:13
Message:
Logged In: YES
user_id=737219
BTW you can please change
"Membership Management" in "Mitgliederverwaltung"
and "Privacy Options" in "Sicherheitseinstellungen"
as used in older versions. :)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=776850&group_i…
Bugs item #785450, was opened at 2003-08-08 11:37
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=785450&group_i…
Category: None
Group: 2.1 (stable)
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Kevin N Carpenter (kevinc_63366)
Assigned to: Nobody/Anonymous (nobody)
Summary: scripts/driver bug
Initial Comment:
One of my primary list is broke. The other lists appear
to be fine. Any help would be greatly appreciated!
Note that this occurred in 2.1.0 - I upgraded to 2.1.2
but the problem still exist.
Bug in Mailman version 2.1.2
We're sorry, we hit a bug!
If you would like to help us identify the problem, please
email a copy of this page to the webmaster for this site
with a description of what happened. Thanks!
Traceback:
Traceback (most recent call last):
File "/usr/local/mailman/scripts/driver", line 87, in
run_main
main()
File "/usr/local/mailman/Mailman/Cgi/admindb.py",
line 85, in main
mlist = MailList.MailList(listname, lock=0)
File "/usr/local/mailman/Mailman/MailList.py", line
124, in __init__
self.Load()
File "/usr/local/mailman/Mailman/MailList.py", line
583, in Load
dict, e = self.__load(file)
File "/usr/local/mailman/Mailman/MailList.py", line
556, in __load
dict = loadfunc(fp)
UnpicklingError: invalid load key, 'n'.
-------------------------------------------------------------
-------------------
Python information:
Variable Value
sys.version 2.2.3 (#1, Aug 7 2003, 19:30:01) [GCC
3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r1, propolice)]
sys.executable /usr/bin/python
sys.prefix /usr
sys.exec_prefix /usr
sys.path /usr
sys.platform linux2
-------------------------------------------------------------
-------------------
Environment variables:
Variable Value
PYTHONPATH /usr/local/mailman
SERVER_SOFTWARE Apache/1.3.27 (Unix)
(Gentoo/Linux) PHP/4.3.1
SCRIPT_FILENAME /home/mailman/cgi-bin/admindb
SERVER_ADMIN root@localhost
SCRIPT_NAME /mailman/admindb
SERVER_SIGNATURE Apache/1.3.27 Server at
mail.seaplace.org Port 80
REQUEST_METHOD GET
HTTP_HOST www.seaplace.org
PATH_INFO /reefkeepers
SERVER_PROTOCOL HTTP/1.0
QUERY_STRING
REQUEST_URI /mailman/admindb/reefkeepers
HTTP_ACCEPT */*
PATH_TRANSLATED /home/httpd/htdocs/reefkeepers
HTTP_USER_AGENT Mozilla/4.0 (compatible; MSIE 6.0;
Windows NT 5.1; Mon_AutoConfig_v1.02_STL; .NET
CLR 1.0.3705; .NET CLR 1.1.4322)
HTTP_CONNECTION keep-alive
SERVER_NAME mail.seaplace.org
REMOTE_ADDR 199.89.234.122
HTTP_X_FORWARDED_FOR 10.133.116.235
REMOTE_PORT 21100
HTTP_ACCEPT_LANGUAGE en-us
HTTP_VIA 1.1 ics_server.monsanto.com (ICS 2.2.76)
SERVER_ADDR 66.128.118.35
SERVER_PORT 80
GATEWAY_INTERFACE CGI/1.1
HTTP_ACCEPT_ENCODING gzip, deflate
UNIQUE_ID PzPApEKAdiMAAF4RtrM
DOCUMENT_ROOT /home/httpd/htdocs
----------------------------------------------------------------------
>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-12-28 17:48
Message:
Logged In: YES
user_id=12800
This is caused by a corruption in your list's config.pck
file. You should move the config.pck.back file to
config.pck to restore your list's configuration to the last
uncorrupted state. If that doesn't work, you'll have to
restore it from backup.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=785450&group_i…
Bugs item #759841, was opened at 2003-06-24 14:22
Message generated for change (Comment added) made by tkikuchi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=759841&group_i…
Category: Pipermail
Group: 2.1 (stable)
Status: Open
Resolution: None
>Priority: 8
Submitted By: Pug Bainter (phelim_gervase)
Assigned to: Nobody/Anonymous (nobody)
Summary: Multipart/mixed issues in archives
Initial Comment:
We are having problems with mailing lists that are not
being properly stripped down to text content in the
archives. When there is multipart/mixed, it doesn't
pull the multipart/alternative sections into their
appropriate text portions.
For example, from content such as the following:
==============================================================================
>From ...
[...]
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary=------------InterScan_NT_MIME_Boundary
[...]
This is a multi-part message in MIME format.
--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C336A1.2C7564BC"
Content-Transfer-Encoding: 7bit
------_=_NextPart_001_01C336A1.2C7564BC
Content-Type: text/plain;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Kevin has a pending checkin that addresses the
minss/maxss issue.
=20
[...]
------_=_NextPart_001_01C336A1.2C7564BC
Content-Type: text/html;
charset=us-ascii
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v
=3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:x =3D=20
"urn:schemas-microsoft-com:office:excel" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD><TITLE>Message</TITLE>=
[...]
==============================================================================
I only get the following:
==============================================================================
[64bit-compiler-analysis] RE: vpr analysis
Syyyy Kyyyyy syyyk at yyy.com
Thu Jun 19 14:27:16 CDT 2003
Previous message: [64bit-compiler-analysis] 06-19-03
MSFT 64-Bit C/C++ compiler
+improvement discussion
Next message: [64bit-compiler-analysis] RE: vpr analysis
Messages sorted by: [ date ] [ thread ] [ subject ] [
author ]
--------------------------------------------------------------------------------
Skipped content of type multipart/alternative
--------------------------------------------------------------------------------
Previous message: [64bit-compiler-analysis] 06-19-03
MSFT 64-Bit C/C++ compiler
+improvement discussion
Next message: [64bit-compiler-analysis] RE: vpr analysis
Messages sorted by: [ date ] [ thread ] [ subject ] [
author ]
--------------------------------------------------------------------------------
More information about the 64bit-compiler-analysis
mailing list
==============================================================================
As you can see, the actual content of the
multipart/alternative portion [text/plain and
text/html] were completely stripped out instead of
being shown a plain text.
----------------------------------------------------------------------
>Comment By: Tokio Kikuchi (tkikuchi)
Date: 2003-12-28 01:17
Message:
Logged In: YES
user_id=67709
The patch by q7joey is merged into my Scrubber.py patch
#866238. I hope Barry can integrate it in 2.1.4.
----------------------------------------------------------------------
Comment By: Joe Pruett (q7joey)
Date: 2003-09-27 16:48
Message:
Logged In: YES
user_id=559223
i have a few line patch that seems to make it do what is
expected.
i can't see how to attach via sourceforge yet, so i'll paste
it here:
---
/usr/local/src/mailman-2.1.2/Mailman/Handlers/Scrubber.py
Fri Feb 7 23:13:50 2003
+++ ./Scrubber.py Sat Sep 27 08:58:46 2003
@@ -286,11 +286,13 @@
# BAW: Martin's original patch suggested we might
want to try
# generalizing to utf-8, and that's probably a good
idea (eventually).
text = []
- for part in msg.get_payload():
+ for part in msg.walk():
+ if part.get_main_type() == 'multipart':
+ continue
# All parts should be scrubbed to text/plain by
now.
partctype = part.get_content_type()
if partctype <> 'text/plain':
- text.append(_('Skipped content of type
%(partctype)s'))
+ text.append(_('Skipped content of type
%(partctype)s\n'))
continue
try:
t = part.get_payload(decode=1)
----------------------------------------------------------------------
Comment By: Martin RJ. Cleaver (mrjc)
Date: 2003-09-27 07:23
Message:
Logged In: YES
user_id=50125
This fails for many of my users as they habitually attach a
photo of themselves in their signatures. They are incredulous
at the idea that mailman can't handle it.
Thanks
----------------------------------------------------------------------
Comment By: Joe Pruett (q7joey)
Date: 2003-09-27 01:26
Message:
Logged In: YES
user_id=559223
i agree that this should be a high priority issue. a simple
message with just multipart/alternative will show up in the
archive ok, but if there is any other kind of attachment,
then the entire multipart section is skipped and you just
get a link for the extra attachment for download/view
ability. i haven't started to look at the code (and i'm not
a python/mailman person), but i'll report anything i can find.
----------------------------------------------------------------------
Comment By: Martin RJ. Cleaver (mrjc)
Date: 2003-09-22 13:34
Message:
Logged In: YES
user_id=50125
Additionally I think it is appropriate to up the priority on this
bug as it causes key functionality to fail.
----------------------------------------------------------------------
Comment By: Martin RJ. Cleaver (mrjc)
Date: 2003-09-22 13:26
Message:
Logged In: YES
user_id=50125
This is causing me real problems! Is there any known
workarounds?
If I can't fix this I might have to use a different package as
presently all my archives are useless!
----------------------------------------------------------------------
Comment By: Pug Bainter (phelim_gervase)
Date: 2003-06-24 17:01
Message:
Logged In: YES
user_id=484284
This appears to be within:
def process(mlist, msg, msgdata=None):
at around line 276, but I saw no way of making it recurse
for multipart/[mixed|alternative] sub-MIME parts.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=759841&group_i…
Patches item #866238, was opened at 2003-12-27 07:59
Message generated for change (Comment added) made by tkikuchi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=866238&group_i…
Category: internationalization
Group: Mailman 2.1
Status: Open
Resolution: None
>Priority: 8
Submitted By: Tokio Kikuchi (tkikuchi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Scrubber for multi-charset language
Initial Comment:
Mailman i18n allows multi-charset for one language eg.
for Japanese, 'iso-2022-jp' for mail message and
'euc-jp' for HTML and internal texts. Scrubber.py fails
to recognize the latter charset by using
get_content_charset() which is getting the mail message
charset.
Example of this bug is in
http://snow.is.kochi-u.ac.jp/pipermail2/mailman2/2003-December/000013.html
while we want to get
http://snow.is.kochi-u.ac.jp/pipermail2/mailman2/2003-December/000017.html
(Compare using their source because your browser may
not capable of displaying japanese fonts)
This patch tries to use get_charset() first, and if it
is empty, use get_content_charset(). Note that the
former returns Charset instance not charset string.
----------------------------------------------------------------------
>Comment By: Tokio Kikuchi (tkikuchi)
Date: 2003-12-28 01:14
Message:
Logged In: YES
user_id=67709
Uploading a revised patch to include bug #759841
(multipart/alternative archive) patch.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=866238&group_i…
Patches item #865661, was opened at 2003-12-25 12:35
Message generated for change (Comment added) made by tkikuchi
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=865661&group_i…
Category: internationalization
Group: Mailman 2.1
Status: Closed
Resolution: Accepted
Priority: 9
Submitted By: Tokio Kikuchi (tkikuchi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Collection of i18n patches
Initial Comment:
This patch works for
1. _at_ substitution for archive.
2. MIME decoded subject and message body in admindb
pending post list.
3. i18n personalization.
4. Header/Footer charset adjusting for multiple
charset. (works for Latin-15/1 problem, I believe.)
5. i18n message held notice.
6. fix for scrubber bug (atatched message).
7. i18n checkdbs.
This collection of patch is for most recent CVS
(2.1.4b) as of 12/25/2003 and I hope this is included
in 2.1.4-release.
----------------------------------------------------------------------
>Comment By: Tokio Kikuchi (tkikuchi)
Date: 2003-12-27 08:02
Message:
Logged In: YES
user_id=67709
Thank you and OK, Barry.
I have submitted a new patch for Scrubber.py which is more
descriptive about the problem, I believe.
----------------------------------------------------------------------
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-12-27 00:58
Message:
Logged In: YES
user_id=12800
I have applied all but the Decorate.py chunk and the
Scrubber.py chunk. For Scrubber, please answer the
questions below. For Decorate, I'm a little uncomfortable
with apply this big of a patch so late in the game.
My suggestion would be to split the remaining two patches up
into separate (new) SF tracker items. I'm closing this one.
----------------------------------------------------------------------
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-12-26 22:47
Message:
Logged In: YES
user_id=12800
The Utils.py patch to include oneline() had some problems:
- it didn't import email.Header or define UEMPTYSTRING
- it shouldn't use oneline as a local var if the function is
called oneline
Both are fixable.
----------------------------------------------------------------------
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-12-26 20:47
Message:
Logged In: YES
user_id=12800
In Scrubber.py, can you explain more why this part is there:
+ # TK: We (Japanese) need to stringify and re-generate
the message
+ # instance because multiple charsets are used.
+ try:
+ msg = message_from_string(str(msg))
+ except UnicodeError:
+ pass
IOW, why do you need to stringify and then re-parse the
message? Can you provide an example message that this fixes?
----------------------------------------------------------------------
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-12-26 18:36
Message:
Logged In: YES
user_id=12800
See attached Encoders.py-for-py234.txt for a patch to
Encoders.py that doesn't break the Python 2.3.x test suite.
----------------------------------------------------------------------
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-12-26 18:23
Message:
Logged In: YES
user_id=12800
Okay, I see the patches to email/Charset.py and
email/Encoders.py. I think I understand the fix to
Encoders.py, but not really the fix to Charset.py. Could
you explain in more detail? Also, please provide test cases
for these changes.
----------------------------------------------------------------------
Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-12-26 17:00
Message:
Logged In: YES
user_id=12800
Can you explain more what you mean by:
"You may need patch email package to properly encode plain
text with base64. (And others for Japanese messages)"
----------------------------------------------------------------------
Comment By: Tokio Kikuchi (tkikuchi)
Date: 2003-12-26 07:23
Message:
Logged In: YES
user_id=67709
Sorry but CJKCodecs was too big to upload in this patch
area. You can download it from
http://mm.tkikuchi.net/CJKCodecs-1.0.tar.gz
Cheers,
----------------------------------------------------------------------
Comment By: Tokio Kikuchi (tkikuchi)
Date: 2003-12-26 07:20
Message:
Logged In: YES
user_id=67709
You may need patch email package to properly encode plain
text with base64. (And others for Japanese messages)
----------------------------------------------------------------------
Comment By: Tokio Kikuchi (tkikuchi)
Date: 2003-12-26 07:16
Message:
Logged In: YES
user_id=67709
u Uploading CJKCodecs 1.0 because their site has only CVS
and no package to download.
----------------------------------------------------------------------
Comment By: Tokio Kikuchi (tkikuchi)
Date: 2003-12-26 07:11
Message:
Logged In: YES
user_id=67709
Update of patch. espacially:
1. improve in 4 above
2. Use of CJKCodecs instead of Japanese and Korean. Now we
can use Chinese.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=865661&group_i…