Mailman-coders
Threads by month
- ----- 2024 -----
- April
- March
- February
- January
- ----- 2023 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2022 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2021 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2020 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2019 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2018 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2017 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2016 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2015 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2014 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2013 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2012 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2011 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2010 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2009 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2008 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2007 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2006 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2005 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2004 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
- ----- 2003 -----
- December
- November
- October
- September
- August
- July
- June
- May
- April
- March
- February
- January
November 2007
- 1 participants
- 26 discussions
Bugs item #759841, was opened at 2003-06-24 07:22
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=759841&group_i…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pipermail
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 8
Private: No
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: Mark Sapiro (msapiro)
Date: 2007-11-06 14:22
Message:
Logged In: YES
user_id=1123998
Originator: NO
You are correct. I was thinking that without the header, the following
text would be a preamble, but this is not the case.
There does appear to be a problem here, and I will look into it further.
The reconstructed message helps alot. Thanks for that.
BTW, the problem is not with pipermail. The message is processed by
Mailman/Handlers/Scrubber.py and flattened to plain text before pipermail
ever sees it. I have verified that the underlying Python email library
parses the MIME structure correctly and sees the body as a text/plain
part.
I have some ideas, but I haven't looked closely enough to be sure. I'll
post again when I know more.
----------------------------------------------------------------------
Comment By: Daniel Kahn Gillmor (rekt)
Date: 2007-11-06 13:05
Message:
Logged In: YES
user_id=842404
Originator: NO
Just did a bit of digging. It looks like section 5.2 of RFC 2045 suggests
that missing content-types should be treated as:
Content-type: text/plain; charset=us-ascii
While i agree that it would be better for the sending MUA to include an
explicit content-type for each mime part (i'm about to file a bug against
the MUA), it seems problematic for pipermail to refuse to render such a
part at all.
----------------------------------------------------------------------
Comment By: Daniel Kahn Gillmor (rekt)
Date: 2007-11-06 12:55
Message:
Logged In: YES
user_id=842404
Originator: NO
Thanks for the response, msapiro. marc.info's raw copy of it looks
basically identical to the version of that message that arrived in my
inbox, so i'd say it's a correct copy. The RFC822 headers for the raw
message were:
Return-Path: <openssh-unix-dev-bounces(a)mindrot.org>
To: <openssh-unix-dev(a)mindrot.org>
Subject: Re: scp -t . - possible idea for additional parameter
From: Daniel Kahn Gillmor <dkg-openssh.com(a)fifthhorseman.net>
Date: Thu, 11 Oct 2007 12:34:23 -0400
Message-ID: <87y7e9d300.fsf(a)squeak.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1431543891=="
When i supply the concatenation of those headers, a blank line, and then
the raw message to msglint, the IETF's message validator [0], it outputs:
-----------
OK: found part multipart/mixed line 10
OK: preamble 10:
OK: found part multipart/signed line 15
OK: preamble 15:
OK: found default part text/plain line 18
OK: found part application/pgp-signature line 67
OK: epilogue 86:
WARNING: MIME headers should only be 'Content-*'. No meaning will apply to
header 'MIME-Version' at line 89
OK: found part text/plain line 93
-----------
So that validator doesn't have any problem with the message (it assumes
the part starting at line 18, which is the section you're suggesting is
invalid, is text/plain). Is the validator wrong in assuming that? I don't
know the relevant specifications well enough to tell myself. Can you show
me where it's a requirement that each MIME section have a content-type?
Thanks for looking into this.
[0] http://www.apps.ietf.org/msglint.html
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2007-11-06 12:04
Message:
Logged In: YES
user_id=1123998
Originator: NO
I can't tell for sure, but the message at
<http://marc.info/?l=openssh-unix-dev&m=119212056224122&w=2> appears to be
malformed. If I go to
<http://marc.info/?l=openssh-unix-dev&m=119212056224122&q=raw> to view the
alleged raw message, I see at the beginning:
--===============1431543891==
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha1; protocol="application/pgp-signature"
--=-=-=
On Thu 2007-10-11 11:00:41 -0400, Larry Becke wrote:
...
I expect to see something like:
--===============1431543891==
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha1; protocol="application/pgp-signature"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--=-=-=
Content-Type: text/plain; charset=...
Content-Transfer-Encoding: ...
On Thu 2007-10-11 11:00:41 -0400, Larry Becke wrote:
...
I.e., I don't see a Content-Type: header for the message body. If it is in
fact missing, that would cause Mailman's behavior in this case, but it is
the message that is at fault, not Mailman.
So the question is whether or not the alleged raw message is in fact a
true representation. If it is, then I think it is the sender's MUA that is
at fault.
----------------------------------------------------------------------
Comment By: Daniel Kahn Gillmor (rekt)
Date: 2007-11-06 10:52
Message:
Logged In: YES
user_id=842404
Originator: NO
This bug (or something very similar to it) seems to still be a problem.
Consider the message here:
http://marc.info/?l=openssh-unix-dev&m=119212056224122&w=2
and in its pipermail archive:
http://lists.mindrot.org/pipermail/openssh-unix-dev/2007-October/025812.html
----------------------------------------------------------------------
Comment By: Joe Pruett (q7joey)
Date: 2005-03-17 21:00
Message:
Logged In: YES
user_id=559223
i just looked at the cvs closer and i see that the patch is
on the 2.1 branch, but hasn't made it into the trunk yet.
----------------------------------------------------------------------
Comment By: Joe Pruett (q7joey)
Date: 2005-03-17 20:52
Message:
Logged In: YES
user_id=559223
i just started working on a 2.1.5 system and discovered that
this bug was still there. from looking in cvs, it appears
to be fixed there (although it seems to reference an
unrelated bugid).
updating this bug to reflect the cvs update would be nice.
----------------------------------------------------------------------
Comment By: Tokio Kikuchi (tkikuchi)
Date: 2003-12-27 17: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 09: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 00: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-26 18: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 06: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 06: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 10: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…
1
0
Bugs item #759841, was opened at 2003-06-24 10:22
Message generated for change (Comment added) made by rekt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=759841&group_i…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pipermail
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 8
Private: No
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: Daniel Kahn Gillmor (rekt)
Date: 2007-11-06 16:05
Message:
Logged In: YES
user_id=842404
Originator: NO
Just did a bit of digging. It looks like section 5.2 of RFC 2045 suggests
that missing content-types should be treated as:
Content-type: text/plain; charset=us-ascii
While i agree that it would be better for the sending MUA to include an
explicit content-type for each mime part (i'm about to file a bug against
the MUA), it seems problematic for pipermail to refuse to render such a
part at all.
----------------------------------------------------------------------
Comment By: Daniel Kahn Gillmor (rekt)
Date: 2007-11-06 15:55
Message:
Logged In: YES
user_id=842404
Originator: NO
Thanks for the response, msapiro. marc.info's raw copy of it looks
basically identical to the version of that message that arrived in my
inbox, so i'd say it's a correct copy. The RFC822 headers for the raw
message were:
Return-Path: <openssh-unix-dev-bounces(a)mindrot.org>
To: <openssh-unix-dev(a)mindrot.org>
Subject: Re: scp -t . - possible idea for additional parameter
From: Daniel Kahn Gillmor <dkg-openssh.com(a)fifthhorseman.net>
Date: Thu, 11 Oct 2007 12:34:23 -0400
Message-ID: <87y7e9d300.fsf(a)squeak.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1431543891=="
When i supply the concatenation of those headers, a blank line, and then
the raw message to msglint, the IETF's message validator [0], it outputs:
-----------
OK: found part multipart/mixed line 10
OK: preamble 10:
OK: found part multipart/signed line 15
OK: preamble 15:
OK: found default part text/plain line 18
OK: found part application/pgp-signature line 67
OK: epilogue 86:
WARNING: MIME headers should only be 'Content-*'. No meaning will apply to
header 'MIME-Version' at line 89
OK: found part text/plain line 93
-----------
So that validator doesn't have any problem with the message (it assumes
the part starting at line 18, which is the section you're suggesting is
invalid, is text/plain). Is the validator wrong in assuming that? I don't
know the relevant specifications well enough to tell myself. Can you show
me where it's a requirement that each MIME section have a content-type?
Thanks for looking into this.
[0] http://www.apps.ietf.org/msglint.html
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2007-11-06 15:04
Message:
Logged In: YES
user_id=1123998
Originator: NO
I can't tell for sure, but the message at
<http://marc.info/?l=openssh-unix-dev&m=119212056224122&w=2> appears to be
malformed. If I go to
<http://marc.info/?l=openssh-unix-dev&m=119212056224122&q=raw> to view the
alleged raw message, I see at the beginning:
--===============1431543891==
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha1; protocol="application/pgp-signature"
--=-=-=
On Thu 2007-10-11 11:00:41 -0400, Larry Becke wrote:
...
I expect to see something like:
--===============1431543891==
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha1; protocol="application/pgp-signature"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--=-=-=
Content-Type: text/plain; charset=...
Content-Transfer-Encoding: ...
On Thu 2007-10-11 11:00:41 -0400, Larry Becke wrote:
...
I.e., I don't see a Content-Type: header for the message body. If it is in
fact missing, that would cause Mailman's behavior in this case, but it is
the message that is at fault, not Mailman.
So the question is whether or not the alleged raw message is in fact a
true representation. If it is, then I think it is the sender's MUA that is
at fault.
----------------------------------------------------------------------
Comment By: Daniel Kahn Gillmor (rekt)
Date: 2007-11-06 13:52
Message:
Logged In: YES
user_id=842404
Originator: NO
This bug (or something very similar to it) seems to still be a problem.
Consider the message here:
http://marc.info/?l=openssh-unix-dev&m=119212056224122&w=2
and in its pipermail archive:
http://lists.mindrot.org/pipermail/openssh-unix-dev/2007-October/025812.html
----------------------------------------------------------------------
Comment By: Joe Pruett (q7joey)
Date: 2005-03-18 00:00
Message:
Logged In: YES
user_id=559223
i just looked at the cvs closer and i see that the patch is
on the 2.1 branch, but hasn't made it into the trunk yet.
----------------------------------------------------------------------
Comment By: Joe Pruett (q7joey)
Date: 2005-03-17 23:52
Message:
Logged In: YES
user_id=559223
i just started working on a 2.1.5 system and discovered that
this bug was still there. from looking in cvs, it appears
to be fixed there (although it seems to reference an
unrelated bugid).
updating this bug to reflect the cvs update would be nice.
----------------------------------------------------------------------
Comment By: Tokio Kikuchi (tkikuchi)
Date: 2003-12-27 20: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 12: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 03: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-26 21: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 09: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 09: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 13: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…
1
0
Bugs item #759841, was opened at 2003-06-24 10:22
Message generated for change (Comment added) made by rekt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=759841&group_i…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pipermail
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 8
Private: No
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: Daniel Kahn Gillmor (rekt)
Date: 2007-11-06 15:55
Message:
Logged In: YES
user_id=842404
Originator: NO
Thanks for the response, msapiro. marc.info's raw copy of it looks
basically identical to the version of that message that arrived in my
inbox, so i'd say it's a correct copy. The RFC822 headers for the raw
message were:
Return-Path: <openssh-unix-dev-bounces(a)mindrot.org>
To: <openssh-unix-dev(a)mindrot.org>
Subject: Re: scp -t . - possible idea for additional parameter
From: Daniel Kahn Gillmor <dkg-openssh.com(a)fifthhorseman.net>
Date: Thu, 11 Oct 2007 12:34:23 -0400
Message-ID: <87y7e9d300.fsf(a)squeak.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1431543891=="
When i supply the concatenation of those headers, a blank line, and then
the raw message to msglint, the IETF's message validator [0], it outputs:
-----------
OK: found part multipart/mixed line 10
OK: preamble 10:
OK: found part multipart/signed line 15
OK: preamble 15:
OK: found default part text/plain line 18
OK: found part application/pgp-signature line 67
OK: epilogue 86:
WARNING: MIME headers should only be 'Content-*'. No meaning will apply to
header 'MIME-Version' at line 89
OK: found part text/plain line 93
-----------
So that validator doesn't have any problem with the message (it assumes
the part starting at line 18, which is the section you're suggesting is
invalid, is text/plain). Is the validator wrong in assuming that? I don't
know the relevant specifications well enough to tell myself. Can you show
me where it's a requirement that each MIME section have a content-type?
Thanks for looking into this.
[0] http://www.apps.ietf.org/msglint.html
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2007-11-06 15:04
Message:
Logged In: YES
user_id=1123998
Originator: NO
I can't tell for sure, but the message at
<http://marc.info/?l=openssh-unix-dev&m=119212056224122&w=2> appears to be
malformed. If I go to
<http://marc.info/?l=openssh-unix-dev&m=119212056224122&q=raw> to view the
alleged raw message, I see at the beginning:
--===============1431543891==
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha1; protocol="application/pgp-signature"
--=-=-=
On Thu 2007-10-11 11:00:41 -0400, Larry Becke wrote:
...
I expect to see something like:
--===============1431543891==
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha1; protocol="application/pgp-signature"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--=-=-=
Content-Type: text/plain; charset=...
Content-Transfer-Encoding: ...
On Thu 2007-10-11 11:00:41 -0400, Larry Becke wrote:
...
I.e., I don't see a Content-Type: header for the message body. If it is in
fact missing, that would cause Mailman's behavior in this case, but it is
the message that is at fault, not Mailman.
So the question is whether or not the alleged raw message is in fact a
true representation. If it is, then I think it is the sender's MUA that is
at fault.
----------------------------------------------------------------------
Comment By: Daniel Kahn Gillmor (rekt)
Date: 2007-11-06 13:52
Message:
Logged In: YES
user_id=842404
Originator: NO
This bug (or something very similar to it) seems to still be a problem.
Consider the message here:
http://marc.info/?l=openssh-unix-dev&m=119212056224122&w=2
and in its pipermail archive:
http://lists.mindrot.org/pipermail/openssh-unix-dev/2007-October/025812.html
----------------------------------------------------------------------
Comment By: Joe Pruett (q7joey)
Date: 2005-03-18 00:00
Message:
Logged In: YES
user_id=559223
i just looked at the cvs closer and i see that the patch is
on the 2.1 branch, but hasn't made it into the trunk yet.
----------------------------------------------------------------------
Comment By: Joe Pruett (q7joey)
Date: 2005-03-17 23:52
Message:
Logged In: YES
user_id=559223
i just started working on a 2.1.5 system and discovered that
this bug was still there. from looking in cvs, it appears
to be fixed there (although it seems to reference an
unrelated bugid).
updating this bug to reflect the cvs update would be nice.
----------------------------------------------------------------------
Comment By: Tokio Kikuchi (tkikuchi)
Date: 2003-12-27 20: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 12: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 03: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-26 21: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 09: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 09: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 13: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…
1
0
Bugs item #759841, was opened at 2003-06-24 07:22
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=759841&group_i…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pipermail
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 8
Private: No
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: Mark Sapiro (msapiro)
Date: 2007-11-06 12:04
Message:
Logged In: YES
user_id=1123998
Originator: NO
I can't tell for sure, but the message at
<http://marc.info/?l=openssh-unix-dev&m=119212056224122&w=2> appears to be
malformed. If I go to
<http://marc.info/?l=openssh-unix-dev&m=119212056224122&q=raw> to view the
alleged raw message, I see at the beginning:
--===============1431543891==
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha1; protocol="application/pgp-signature"
--=-=-=
On Thu 2007-10-11 11:00:41 -0400, Larry Becke wrote:
...
I expect to see something like:
--===============1431543891==
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha1; protocol="application/pgp-signature"
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--=-=-=
Content-Type: text/plain; charset=...
Content-Transfer-Encoding: ...
On Thu 2007-10-11 11:00:41 -0400, Larry Becke wrote:
...
I.e., I don't see a Content-Type: header for the message body. If it is in
fact missing, that would cause Mailman's behavior in this case, but it is
the message that is at fault, not Mailman.
So the question is whether or not the alleged raw message is in fact a
true representation. If it is, then I think it is the sender's MUA that is
at fault.
----------------------------------------------------------------------
Comment By: Daniel Kahn Gillmor (rekt)
Date: 2007-11-06 10:52
Message:
Logged In: YES
user_id=842404
Originator: NO
This bug (or something very similar to it) seems to still be a problem.
Consider the message here:
http://marc.info/?l=openssh-unix-dev&m=119212056224122&w=2
and in its pipermail archive:
http://lists.mindrot.org/pipermail/openssh-unix-dev/2007-October/025812.html
----------------------------------------------------------------------
Comment By: Joe Pruett (q7joey)
Date: 2005-03-17 21:00
Message:
Logged In: YES
user_id=559223
i just looked at the cvs closer and i see that the patch is
on the 2.1 branch, but hasn't made it into the trunk yet.
----------------------------------------------------------------------
Comment By: Joe Pruett (q7joey)
Date: 2005-03-17 20:52
Message:
Logged In: YES
user_id=559223
i just started working on a 2.1.5 system and discovered that
this bug was still there. from looking in cvs, it appears
to be fixed there (although it seems to reference an
unrelated bugid).
updating this bug to reflect the cvs update would be nice.
----------------------------------------------------------------------
Comment By: Tokio Kikuchi (tkikuchi)
Date: 2003-12-27 17: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 09: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 00: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-26 18: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 06: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 06: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 10: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…
1
0
Bugs item #759841, was opened at 2003-06-24 10:22
Message generated for change (Comment added) made by rekt
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=759841&group_i…
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Pipermail
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 8
Private: No
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: Daniel Kahn Gillmor (rekt)
Date: 2007-11-06 13:52
Message:
Logged In: YES
user_id=842404
Originator: NO
This bug (or something very similar to it) seems to still be a problem.
Consider the message here:
http://marc.info/?l=openssh-unix-dev&m=119212056224122&w=2
and in its pipermail archive:
http://lists.mindrot.org/pipermail/openssh-unix-dev/2007-October/025812.html
----------------------------------------------------------------------
Comment By: Joe Pruett (q7joey)
Date: 2005-03-18 00:00
Message:
Logged In: YES
user_id=559223
i just looked at the cvs closer and i see that the patch is
on the 2.1 branch, but hasn't made it into the trunk yet.
----------------------------------------------------------------------
Comment By: Joe Pruett (q7joey)
Date: 2005-03-17 23:52
Message:
Logged In: YES
user_id=559223
i just started working on a 2.1.5 system and discovered that
this bug was still there. from looking in cvs, it appears
to be fixed there (although it seems to reference an
unrelated bugid).
updating this bug to reflect the cvs update would be nice.
----------------------------------------------------------------------
Comment By: Tokio Kikuchi (tkikuchi)
Date: 2003-12-27 20: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 12: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 03: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-26 21: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 09: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 09: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 13: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…
1
0
01 Nov '07
Feature Requests item #1822565, was opened at 2007-10-30 00:33
Message generated for change (Comment added) made by msapiro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1822565&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: Cyndi (cyndi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Plain text option for nondigest
Initial Comment:
I searched this to the best of my ability and there seems to be no current method to do it. I found this:
http://www.mail-archive.com/mailman-users@python.org/msg36881.html
and searched the feature requests, but it seems no one has submitted this yet, as far as I can tell.
You have a plain-text option for subscribers to select if they receive the digest. I've tested it and it works perfectly. Messages that came through as HTML gobblygook in the nondigest will display as lovely plain text in the digest.
What I would love is a plain-text option for the nondigest. Just exactly what you do for the digests, only post by post. Yahoogroups does it, as do many other mailing list sites/programs.
It seems that currently I have only three choices:
1) Convert all posts to plain text. I can't get this to work right though (I am using a hosting service via my ISP, so they may not have all the prereqs, or I need to tweak it more myself). But this means people who want HTML can't get it.
2) Get MM to hold all HTML posts for moderation, then I send rejection notices insisting that people post in plain text only. This "works" but disenfranchises people with poor email skills or who use mailers/ISP's like AOL. I run a support group filled with people who have brain processing deficits, as well as those who simply don't understand computers. I've tried for years to get folks to post in plain text and most just can't. I finally gave up and hand-edited the HTML posts, but this isn't possible on MM (and I hate doing it).
3) Live with it. Most people have HTML-capable mailers (I'm an oldtimer holdout, but can switch). The problem is that some of my subscribers are blind or otherwise can't deal with HTML-formatted email (not all have converting software).
A choice #4 (user option for nondigest plain text) would be wonderful.
Thanks.
----------------------------------------------------------------------
>Comment By: Mark Sapiro (msapiro)
Date: 2007-10-31 21:02
Message:
Logged In: YES
user_id=1123998
Originator: NO
As far as I can tell, sonic.net runs a more or less standard 2.1.9
version. At least it doesn't have a 'package identifier'.
<quote>
When someone posts to the test list in HTML, I get gobbygook in the
individual posts. The readability varies, depending on their mailer and
settings.
</quote>
Is this using the non MIME/HTML aware reader? Is mail from the list any
different from mail you would see if they sent the mail to you directly in
the same way? Does this list mail look 'normal' if you view it in a
MIME/HTML aware reader?
<quote>
So the same emails are coming through
differently in nondigest (no conversion) and digest (plain text
conversion).
</quote>
In standard mailman, no conversion whatsoever is done for the plain text
digest. The messages are passed through exactly the same scrubber process
as is used for scrub_nondigest. This process removes every non text/plain
MIME part and every text/plain MIME part with an unknown character set and
stores these parts separately and replaces them with links to the stored
parts exactly as you indicate.
What I'm trying to tell you is this process is not different for
individual messages with scrub_nondigest vs. the plain text digest. That's
the part where I have a problem with what you are saying, since you are
saying the individual message received with scrub_nondigest is unacceptable
but a similar message in the plain text digest is acceptable, but I am
saying the messages are produced in exactly the same way unless sonic.net's
Mailman has modifications in the production of plain text digests of which
I am not aware.
Regarding the scrubbed HTML attachment, I can't view it because it is in a
private archive, but I imagine your complaint is because you are seeing
'html escaped' text rather than rendered HTML. It is possible for a site to
choose to save this as HTML rather than 'escaped' HTML, but it is not
recommended because it exposes the site to injection of any and all types
of malicious HTML via emails to a list which the site will then serve to
web visitors - not a good thing.
<quote>
My plain text posts came through fine (just like they did before using the
scrub_nondigest setting), but anything with HTML or a graphic got the
treatment above.
</quote>
And are not posts with HTML and/or graphics given exactly the same
treatment in the plain text digest?
<quote>
So, I turned the scrub_nondigest setting back off and went to the Content
Filtering page. I turned it on and removed the attachment types but
otherwise left defaults as is. I got errors similar to those with
scrub_nondigest. Perhaps I need to put more of the defaults back in; I am
willing to play with it if I can find some clear directions.
</quote>
Are you saying that now the messages in the plain text digest look like
the individual scrub-nondigest messages did? If so, I'm not surprised
because that's what I think the case should be. If this appeared to not be
the case before, perhaps it is as I said yesterday.
<quote>
Perhaps when you tested the digest, you looked at a multipart/alternative
message and when you tested scrub_nondigest, you looked at an HTML only
message.
</quote>
<quote>
If it would be helpful, I would be happy to forward emails to you from my
tests. Or I could run new tests at your request.
</quote>
What I would like to see is a plain text digest that contains a
"converted" HTML message, the original of that HTML message as posted to
the list, and a copy of all the content filtering settings that were in
effect at the time the message was posted. A copy of the original HTML
message as received from the list as an individual message might also be
interesting.
You can put the raw text of those messages including headers in one or
more files and attach them here or you can email the messages to me in any
way that preserves the MIME structure of the messages.
----------------------------------------------------------------------
Comment By: Jim Popovitch (jimpop)
Date: 2007-10-30 23:39
Message:
Logged In: YES
user_id=3142
Originator: NO
Hi Cyndi,
First, I am a huge fan of Mailman as well as a long time administrator of
a Mailman system. Now that I have said that, let me say that I agree with
you that scrub_nondigest doesn't work the way you (nor I) feel it should.
I leave it disabled on our systems. That said, what I think you need is
something like demime before the email hits Mailman. I used that for years
before deciding that HTML email would be ok for our lists. I do understand
your situation is such that you don't have console access to the system,
but perhaps you can ask your hosting provider to supply if for you. Again,
I don't think that scrub_nondigest will do what you need, and there is
little else in Mailman to change the overall format of incoming email
messages. Best wishes. -Jim P.
----------------------------------------------------------------------
Comment By: Cyndi (cyndi)
Date: 2007-10-30 23:23
Message:
Logged In: YES
user_id=1925111
Originator: YES
If I miss a question, or don't give the answer you need, please ask again.
Note that I say "HTML" when I really mean "HTML or MIME or related
encodings."
I am using Mailman on sonic.net. Version 2.1.9. I can't find more
information than that...my guess is that it's being run on a unix box (or
some flavor of linux). If it is modified, I don't know where or how.
I started a mailman test list with 4 other volunteers from my current
(majordomo) list so we can work out the kinks. I am subscribed under two
addresses, so I have digest and nondigest. I use a non-HTML capable mailer
for most of my work, though I have access to HTML/MIME-capable ones. My
volunteers use various ISP's and mailers and mostly post in HTML.
When someone posts to the test list in HTML, I get gobbygook in the
individual posts. The readability varies, depending on their mailer and
settings. Then I did my new subscription address and chose digest with
plain text. The digests are completely readable with no HTML code or
anything else like that. This includes digests made up of posts that were
HTML/junk in nondigest mail. So the same emails are coming through
differently in nondigest (no conversion) and digest (plain text
conversion).
When I tested the scrub_nondigest setting, the posts still went through,
but the content was removed from any that were not sent in plain text. For
example, this was the complete body of one message (the sender posted in
HTML and included a small graphic as part of the test; the MM footer was
appended correctly at the bottom, which I have removed here):
An HTML attachment was scrubbed...
URL:
http://lists.sonic.net/mailman/private/immune-test/attachments/20071028/4b5…
ml
If you go to that URL, you'll see that the message is a complete mess. My
plain text posts came through fine (just like they did before using the
scrub_nondigest setting), but anything with HTML or a graphic got the
treatment above.
So, I turned the scrub_nondigest setting back off and went to the Content
Filtering page. I turned it on and removed the attachment types but
otherwise left defaults as is. I got errors similar to those with
scrub_nondigest. Perhaps I need to put more of the defaults back in; I am
willing to play with it if I can find some clear directions.
If it would be helpful, I would be happy to forward emails to you from my
tests. Or I could run new tests at your request. I've already posted to
sonic.help.lists which is my ISP's internal newsgroup for MM issues (no
replies on that topic yet).
Thanks very much for your discussion and let me know if I failed to answer
a question fully.
Cyndi
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2007-10-30 20:15
Message:
Logged In: YES
user_id=1123998
Originator: NO
Sorry. I didn't read the message you referenced in your original
description. My bad.
However, I don't understand why you say scrub_nondigest "was a total
disaster" and regarding plain digests "I've tested it and it works
perfectly." Exactly the same scrubber process is applied in both cases.
Perhaps when you tested the digest, you looked at a multipart/alternative
message and when you tested scrub_nondigest, you looked at an HTML only
message. Or perhaps you are using someone else's modified Mailman. If so,
perhaps you could convince them to abide by the terms of the GPL and submit
their patches.
As far as the scrubber links not working well is concerned, the only issue
with current Mailman project Mailman that I am aware of is you have to log
in if your archives are private. There are other issues I am aware of with
some cPanel versions, but those are beyond our control. What problems did
you have, and what Mailman version is this?
HTML to plain text conversion relies on an external program (default
lynx). In older versions of Mailman there were issues because
quoted-printable and base64 encoded HTML was passed to the external program
without decoding, but this was fixed in (I think) 2.1.7.
As far as the request for an individual option is concerned, it is a valid
request, but even though you seem convinced that we know how to do what you
want for digests, I'm not convinced, so we need to resolve that first.
Otherwise you may get a user option for something that you consider
unsatisfactory.
----------------------------------------------------------------------
Comment By: Cyndi (cyndi)
Date: 2007-10-30 19:24
Message:
Logged In: YES
user_id=1925111
Originator: YES
Well, you yourself said that anyone wanting this ability to be per-user
should submit a feature request here (see
http://www.mail-archive.com/mailman-users@python.org/msg36881.html ). So I
did. If it can be per user for digests, I don't see why not for
nondigests, but you know the limitations of the software.
I already tested the scrub_nondigest option and it was a total disaster.
It didn't do any conversion. All it did was take all the text (along with
any attachments) in the message and remove it, then put a link to where to
find it. Even that didn't work well.
I also tested the Content Filtering to do HTML conversion to plain text
and it was even more of a disaster. I found some instructions that
indicate it is very complex to setup, but my browser crashed so I'll have
to look them up again. I think it might be possible to do HTML conversion
on all the posts but only if my ISP agrees to do some stuff on their end.
And it's not straightforward.
For right now, I would be happy with a bug-free way to do conversions for
the entire list. But I still think a feature where the user can choose
HTML or plain text individual posts is a good thing.
----------------------------------------------------------------------
Comment By: Mark Sapiro (msapiro)
Date: 2007-10-30 18:48
Message:
Logged In: YES
user_id=1123998
Originator: NO
Perhaps you didn't search well enough, or perhaps we just hide or don't
describe the option in these terms, but the Non-digest
options->scrub_nondigest option in the list admin interface will do what
you want. It will apply the same process that is applied to the plain
digest to individual messages.
The only problem is this is a list option, not an individual subscriber
option.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1822565&group_…
1
0