From noreply at sourceforge.net  Thu Nov  1 05:02:04 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed, 31 Oct 2007 21:02:04 -0700
Subject: [ mailman-Feature Requests-1822565 ] Plain text option for nondigest
Message-ID: <E1InRFs-00044B-9Y@sc8-sf-web22.sourceforge.net>

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_id=103

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 at 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/4b520cb9/attachment.ht\
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 at 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_id=103

From noreply at sourceforge.net  Tue Nov  6 19:52:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2007 10:52:31 -0800
Subject: [ mailman-Bugs-759841 ] Multipart/mixed issues in archives
Message-ID: <E1IpTXL-0007VY-6J@sc8-sf-web21.sourceforge.net>

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_id=103

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:

==============================================================================
&gt;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=&quot;----_=_NextPart_001_01C336A1.2C7564BC&quot;
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

&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0
Transitional//EN&quot;&gt;
&lt;HTML xmlns=3D&quot;http://www.w3.org/TR/REC-html40&quot; xmlns:v
=3D=20
&quot;urn:schemas-microsoft-com:vml&quot; xmlns:o =3D=20
&quot;urn:schemas-microsoft-com:office:office&quot; xmlns:w =3D=20
&quot;urn:schemas-microsoft-com:office:word&quot; xmlns:x =3D=20
&quot;urn:schemas-microsoft-com:office:excel&quot; xmlns:st1 =3D=20
&quot;urn:schemas-microsoft-com:office:smarttags&quot;&gt;&lt;HEAD&gt;&lt;TITLE&gt;Message&lt;/TITLE&gt;=

[...]
==============================================================================

  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 &lt;&gt; '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_id=103

From noreply at sourceforge.net  Tue Nov  6 21:04:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2007 12:04:31 -0800
Subject: [ mailman-Bugs-759841 ] Multipart/mixed issues in archives
Message-ID: <E1IpUf1-0007B8-Pz@sc8-sf-web21.sourceforge.net>

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_id=103

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:

==============================================================================
&gt;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=&quot;----_=_NextPart_001_01C336A1.2C7564BC&quot;
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

&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0
Transitional//EN&quot;&gt;
&lt;HTML xmlns=3D&quot;http://www.w3.org/TR/REC-html40&quot; xmlns:v
=3D=20
&quot;urn:schemas-microsoft-com:vml&quot; xmlns:o =3D=20
&quot;urn:schemas-microsoft-com:office:office&quot; xmlns:w =3D=20
&quot;urn:schemas-microsoft-com:office:word&quot; xmlns:x =3D=20
&quot;urn:schemas-microsoft-com:office:excel&quot; xmlns:st1 =3D=20
&quot;urn:schemas-microsoft-com:office:smarttags&quot;&gt;&lt;HEAD&gt;&lt;TITLE&gt;Message&lt;/TITLE&gt;=

[...]
==============================================================================

  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 &lt;&gt; '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_id=103

From noreply at sourceforge.net  Tue Nov  6 21:55:48 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2007 12:55:48 -0800
Subject: [ mailman-Bugs-759841 ] Multipart/mixed issues in archives
Message-ID: <E1IpVSe-0004Tu-AI@sc8-sf-web21.sourceforge.net>

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_id=103

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:

==============================================================================
&gt;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=&quot;----_=_NextPart_001_01C336A1.2C7564BC&quot;
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

&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0
Transitional//EN&quot;&gt;
&lt;HTML xmlns=3D&quot;http://www.w3.org/TR/REC-html40&quot; xmlns:v
=3D=20
&quot;urn:schemas-microsoft-com:vml&quot; xmlns:o =3D=20
&quot;urn:schemas-microsoft-com:office:office&quot; xmlns:w =3D=20
&quot;urn:schemas-microsoft-com:office:word&quot; xmlns:x =3D=20
&quot;urn:schemas-microsoft-com:office:excel&quot; xmlns:st1 =3D=20
&quot;urn:schemas-microsoft-com:office:smarttags&quot;&gt;&lt;HEAD&gt;&lt;TITLE&gt;Message&lt;/TITLE&gt;=

[...]
==============================================================================

  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 at mindrot.org>
To: <openssh-unix-dev at mindrot.org>
Subject: Re: scp -t . - possible idea for additional parameter
From: Daniel Kahn Gillmor <dkg-openssh.com at fifthhorseman.net>
Date: Thu, 11 Oct 2007 12:34:23 -0400
Message-ID: <87y7e9d300.fsf at 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 &lt;&gt; '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_id=103

From noreply at sourceforge.net  Tue Nov  6 22:05:20 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2007 13:05:20 -0800
Subject: [ mailman-Bugs-759841 ] Multipart/mixed issues in archives
Message-ID: <E1IpVbs-0005ab-6z@sc8-sf-web21.sourceforge.net>

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_id=103

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:

==============================================================================
&gt;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=&quot;----_=_NextPart_001_01C336A1.2C7564BC&quot;
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

&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0
Transitional//EN&quot;&gt;
&lt;HTML xmlns=3D&quot;http://www.w3.org/TR/REC-html40&quot; xmlns:v
=3D=20
&quot;urn:schemas-microsoft-com:vml&quot; xmlns:o =3D=20
&quot;urn:schemas-microsoft-com:office:office&quot; xmlns:w =3D=20
&quot;urn:schemas-microsoft-com:office:word&quot; xmlns:x =3D=20
&quot;urn:schemas-microsoft-com:office:excel&quot; xmlns:st1 =3D=20
&quot;urn:schemas-microsoft-com:office:smarttags&quot;&gt;&lt;HEAD&gt;&lt;TITLE&gt;Message&lt;/TITLE&gt;=

[...]
==============================================================================

  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 at mindrot.org>
To: <openssh-unix-dev at mindrot.org>
Subject: Re: scp -t . - possible idea for additional parameter
From: Daniel Kahn Gillmor <dkg-openssh.com at fifthhorseman.net>
Date: Thu, 11 Oct 2007 12:34:23 -0400
Message-ID: <87y7e9d300.fsf at 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 &lt;&gt; '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_id=103

From noreply at sourceforge.net  Tue Nov  6 23:22:57 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2007 14:22:57 -0800
Subject: [ mailman-Bugs-759841 ] Multipart/mixed issues in archives
Message-ID: <E1IpWoz-0005nF-H8@sc8-sf-web21.sourceforge.net>

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_id=103

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:

==============================================================================
&gt;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=&quot;----_=_NextPart_001_01C336A1.2C7564BC&quot;
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

&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0
Transitional//EN&quot;&gt;
&lt;HTML xmlns=3D&quot;http://www.w3.org/TR/REC-html40&quot; xmlns:v
=3D=20
&quot;urn:schemas-microsoft-com:vml&quot; xmlns:o =3D=20
&quot;urn:schemas-microsoft-com:office:office&quot; xmlns:w =3D=20
&quot;urn:schemas-microsoft-com:office:word&quot; xmlns:x =3D=20
&quot;urn:schemas-microsoft-com:office:excel&quot; xmlns:st1 =3D=20
&quot;urn:schemas-microsoft-com:office:smarttags&quot;&gt;&lt;HEAD&gt;&lt;TITLE&gt;Message&lt;/TITLE&gt;=

[...]
==============================================================================

  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 at mindrot.org>
To: <openssh-unix-dev at mindrot.org>
Subject: Re: scp -t . - possible idea for additional parameter
From: Daniel Kahn Gillmor <dkg-openssh.com at fifthhorseman.net>
Date: Thu, 11 Oct 2007 12:34:23 -0400
Message-ID: <87y7e9d300.fsf at 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 &lt;&gt; '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_id=103

From noreply at sourceforge.net  Wed Nov  7 01:08:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2007 16:08:13 -0800
Subject: [ mailman-Bugs-1827247 ] add_members does not send welcome message
Message-ID: <E1IpYSr-00009f-Kx@sc8-sf-web24.sourceforge.net>

Bugs item #1827247, was opened at 2007-11-07 01:08
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1827247&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: command line scripts
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Hartwig (thhart)
Assigned to: Nobody/Anonymous (nobody)
Summary: add_members does not send welcome message

Initial Comment:
I use mailman with a CGI script wrapper to add subscribers via add_members. Subscribing succeeds but unfortunately it does not send out the welcome message nor the moderator information. Of course I have said so with the command all possible options, but nothing helps. Even from the console the messages will not be send.
remove_members has the same problem.

mailman: 2.1.9-8
system: Debian GNU/Linux testing (lenny)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1827247&group_id=103

From noreply at sourceforge.net  Wed Nov  7 02:46:07 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2007 17:46:07 -0800
Subject: [ mailman-Bugs-759841 ] Multipart/mixed issues in archives
Message-ID: <E1IpZzb-00066W-L3@sc8-sf-web22.sourceforge.net>

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_id=103

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: Fixed
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:

==============================================================================
&gt;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=&quot;----_=_NextPart_001_01C336A1.2C7564BC&quot;
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

&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0
Transitional//EN&quot;&gt;
&lt;HTML xmlns=3D&quot;http://www.w3.org/TR/REC-html40&quot; xmlns:v
=3D=20
&quot;urn:schemas-microsoft-com:vml&quot; xmlns:o =3D=20
&quot;urn:schemas-microsoft-com:office:office&quot; xmlns:w =3D=20
&quot;urn:schemas-microsoft-com:office:word&quot; xmlns:x =3D=20
&quot;urn:schemas-microsoft-com:office:excel&quot; xmlns:st1 =3D=20
&quot;urn:schemas-microsoft-com:office:smarttags&quot;&gt;&lt;HEAD&gt;&lt;TITLE&gt;Message&lt;/TITLE&gt;=

[...]
==============================================================================

  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 17:46

Message:
Logged In: YES 
user_id=1123998
Originator: NO

It turns out this problem has been observed and discussed at great length
in December of 2006. See the thread that begins at
<http://mail.python.org/pipermail/mailman-users/2006-December/054904.html>.

A few fixes were discussed in that thread but never implemented. I have
now tested a fix along the lines of that discussion and committed it and it
will be in Mailman 2.1.10 (beta release is imminent).

----------------------------------------------------------------------

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 at mindrot.org>
To: <openssh-unix-dev at mindrot.org>
Subject: Re: scp -t . - possible idea for additional parameter
From: Daniel Kahn Gillmor <dkg-openssh.com at fifthhorseman.net>
Date: Thu, 11 Oct 2007 12:34:23 -0400
Message-ID: <87y7e9d300.fsf at 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 &lt;&gt; '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_id=103

From noreply at sourceforge.net  Wed Nov  7 03:47:26 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2007 18:47:26 -0800
Subject: [ mailman-Bugs-759841 ] Multipart/mixed issues in archives
Message-ID: <E1Ipaww-0000Mw-Fj@sc8-sf-web24.sourceforge.net>

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_id=103

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: Fixed
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:

==============================================================================
&gt;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=&quot;----_=_NextPart_001_01C336A1.2C7564BC&quot;
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

&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0
Transitional//EN&quot;&gt;
&lt;HTML xmlns=3D&quot;http://www.w3.org/TR/REC-html40&quot; xmlns:v
=3D=20
&quot;urn:schemas-microsoft-com:vml&quot; xmlns:o =3D=20
&quot;urn:schemas-microsoft-com:office:office&quot; xmlns:w =3D=20
&quot;urn:schemas-microsoft-com:office:word&quot; xmlns:x =3D=20
&quot;urn:schemas-microsoft-com:office:excel&quot; xmlns:st1 =3D=20
&quot;urn:schemas-microsoft-com:office:smarttags&quot;&gt;&lt;HEAD&gt;&lt;TITLE&gt;Message&lt;/TITLE&gt;=

[...]
==============================================================================

  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 21:47

Message:
Logged In: YES 
user_id=842404
Originator: NO

Thank you very much, Mark!

I'm assuming that this is the commit you're talking about:

http://marc.info/?l=mailman-cvs&m=119440136928253&w=2

I just applied the following diff to a debian lenny installation (mailman
2.1.9-8) i've been experimenting on:

--- Scrubber.py.orig    2007-11-06 21:15:30.000000000 -0500
+++ Scrubber.py 2007-11-06 21:16:07.000000000 -0500
@@ -342,7 +342,8 @@
         text = []
         for part in msg.walk():
             # TK: bug-id 1099138 and multipart
-            if not part or part.is_multipart():
+            # MAS test payload - if part may fail if there are no
headers.
+            if not part._payload or part.is_multipart():
                 continue
             # All parts should be scrubbed to text/plain by now.
             partctype = part.get_content_type()

After recompiling Scrubber.py, I then did:

 /var/lib/mailman/bin/arch --wipe testlist

and it fixed a message with a similar formatting issue that had previously
been blank.

My only concern is that in the thread you linked to, it's mentioned that
arch --wipe can break external links.  This makes me reluctant to use it to
fix older archives with blank messages which might have accumulated
external links.  URLs should be stable!  Is this really a possible
consequence of arch --wipe?

----------------------------------------------------------------------

Comment By: Mark Sapiro (msapiro)
Date: 2007-11-06 20:46

Message:
Logged In: YES 
user_id=1123998
Originator: NO

It turns out this problem has been observed and discussed at great length
in December of 2006. See the thread that begins at
<http://mail.python.org/pipermail/mailman-users/2006-December/054904.html>.

A few fixes were discussed in that thread but never implemented. I have
now tested a fix along the lines of that discussion and committed it and it
will be in Mailman 2.1.10 (beta release is imminent).

----------------------------------------------------------------------

Comment By: Mark Sapiro (msapiro)
Date: 2007-11-06 17: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 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 at mindrot.org>
To: <openssh-unix-dev at mindrot.org>
Subject: Re: scp -t . - possible idea for additional parameter
From: Daniel Kahn Gillmor <dkg-openssh.com at fifthhorseman.net>
Date: Thu, 11 Oct 2007 12:34:23 -0400
Message-ID: <87y7e9d300.fsf at 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 &lt;&gt; '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_id=103

From noreply at sourceforge.net  Wed Nov  7 05:27:19 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2007 20:27:19 -0800
Subject: [ mailman-Bugs-759841 ] Multipart/mixed issues in archives
Message-ID: <E1IpcVb-0006Yv-1X@sc8-sf-web22.sourceforge.net>

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_id=103

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: Fixed
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:

==============================================================================
&gt;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=&quot;----_=_NextPart_001_01C336A1.2C7564BC&quot;
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

&lt;!DOCTYPE HTML PUBLIC &quot;-//W3C//DTD HTML 4.0
Transitional//EN&quot;&gt;
&lt;HTML xmlns=3D&quot;http://www.w3.org/TR/REC-html40&quot; xmlns:v
=3D=20
&quot;urn:schemas-microsoft-com:vml&quot; xmlns:o =3D=20
&quot;urn:schemas-microsoft-com:office:office&quot; xmlns:w =3D=20
&quot;urn:schemas-microsoft-com:office:word&quot; xmlns:x =3D=20
&quot;urn:schemas-microsoft-com:office:excel&quot; xmlns:st1 =3D=20
&quot;urn:schemas-microsoft-com:office:smarttags&quot;&gt;&lt;HEAD&gt;&lt;TITLE&gt;Message&lt;/TITLE&gt;=

[...]
==============================================================================

  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 20:27

Message:
Logged In: YES 
user_id=1123998
Originator: NO

Yes, that is the commit I'm talking about.

And, yes it is possible for bin/arch --wipe to break saved URLs/external
links. See
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.033.htp>.

One way in which this can happen is if the cumulative mailbox file
(archives/private/<listname>.mbox/<listname>.mbox) has unescaped "From "
lines in message bodies. This will only be the case with .mbox files that
are 'old' (maybe older than 2.1.x, but I'm not sure) or imported from
another application. The bin/cleanarch script can help find and fix such
lines.

I think there are other ways in which this can happen too, but I'm not
sure what they are, but I am confident that if Mailman isn't running when
you do the bin/arch --wipe, the message numbers in the new archive will get
assigned in mbox order, so the issue is if the original numbers somehow are
not in mbox order.

One thing you can do is stop Mailman, make a backup copy of the
archives/private/<listname>/ directory, run bin/arch --wipe <listname> and
then quickly check sample messages throughout the new and backup archives
to verify they have the same message numbers. If they do, just start
Mailman, If not, restore the backup.

Note that the current plan is to redesign the built-in archiver for
Mailman 3.0 to avoid this problem in the future among other things.

----------------------------------------------------------------------

Comment By: Daniel Kahn Gillmor (rekt)
Date: 2007-11-06 18:47

Message:
Logged In: YES 
user_id=842404
Originator: NO

Thank you very much, Mark!

I'm assuming that this is the commit you're talking about:

http://marc.info/?l=mailman-cvs&m=119440136928253&w=2

I just applied the following diff to a debian lenny installation (mailman
2.1.9-8) i've been experimenting on:

--- Scrubber.py.orig    2007-11-06 21:15:30.000000000 -0500
+++ Scrubber.py 2007-11-06 21:16:07.000000000 -0500
@@ -342,7 +342,8 @@
         text = []
         for part in msg.walk():
             # TK: bug-id 1099138 and multipart
-            if not part or part.is_multipart():
+            # MAS test payload - if part may fail if there are no
headers.
+            if not part._payload or part.is_multipart():
                 continue
             # All parts should be scrubbed to text/plain by now.
             partctype = part.get_content_type()

After recompiling Scrubber.py, I then did:

 /var/lib/mailman/bin/arch --wipe testlist

and it fixed a message with a similar formatting issue that had previously
been blank.

My only concern is that in the thread you linked to, it's mentioned that
arch --wipe can break external links.  This makes me reluctant to use it to
fix older archives with blank messages which might have accumulated
external links.  URLs should be stable!  Is this really a possible
consequence of arch --wipe?

----------------------------------------------------------------------

Comment By: Mark Sapiro (msapiro)
Date: 2007-11-06 17:46

Message:
Logged In: YES 
user_id=1123998
Originator: NO

It turns out this problem has been observed and discussed at great length
in December of 2006. See the thread that begins at
<http://mail.python.org/pipermail/mailman-users/2006-December/054904.html>.

A few fixes were discussed in that thread but never implemented. I have
now tested a fix along the lines of that discussion and committed it and it
will be in Mailman 2.1.10 (beta release is imminent).

----------------------------------------------------------------------

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 at mindrot.org>
To: <openssh-unix-dev at mindrot.org>
Subject: Re: scp -t . - possible idea for additional parameter
From: Daniel Kahn Gillmor <dkg-openssh.com at fifthhorseman.net>
Date: Thu, 11 Oct 2007 12:34:23 -0400
Message-ID: <87y7e9d300.fsf at 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 &lt;&gt; '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_id=103

From noreply at sourceforge.net  Wed Nov  7 06:11:26 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 06 Nov 2007 21:11:26 -0800
Subject: [ mailman-Bugs-1827247 ] add_members does not send welcome message
Message-ID: <E1IpdCI-00007a-V6@sc8-sf-web21.sourceforge.net>

Bugs item #1827247, was opened at 2007-11-06 16:08
Message generated for change (Comment added) made by msapiro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1827247&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: command line scripts
Group: 2.1 (stable)
Status: Open
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Thomas Hartwig (thhart)
Assigned to: Nobody/Anonymous (nobody)
Summary: add_members does not send welcome message

Initial Comment:
I use mailman with a CGI script wrapper to add subscribers via add_members. Subscribing succeeds but unfortunately it does not send out the welcome message nor the moderator information. Of course I have said so with the command all possible options, but nothing helps. Even from the console the messages will not be send.
remove_members has the same problem.

mailman: 2.1.9-8
system: Debian GNU/Linux testing (lenny)

----------------------------------------------------------------------

>Comment By: Mark Sapiro (msapiro)
Date: 2007-11-06 21:11

Message:
Logged In: YES 
user_id=1123998
Originator: NO

There was a bug in that if the list was set to not send welcome messages,
this could not be overridden in add_members or mass subscribe, but this was
fixed in 2.1.9.

I don't see this problem running add_mambers from the command line. I set
the list's send_welcome_message and admin_notify_mchanges off and run
'bin/add_members -r file -w y -a y listname' and the member in 'file'
received the welcome and the admin received the subscribe notice.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1827247&group_id=103

From noreply at sourceforge.net  Fri Nov  9 17:05:55 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Nov 2007 08:05:55 -0800
Subject: [ mailman-Bugs-1829061 ] Email subscribe interface and QP encoding
Message-ID: <E1IqWMl-0003dr-05@sc8-sf-web24.sourceforge.net>

Bugs item #1829061, was opened at 2007-11-09 11:05
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1829061&group_id=103

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: (un)subscribing
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Larry Rosenbaum (lmr_ornl)
Assigned to: Nobody/Anonymous (nobody)
Summary: Email subscribe interface and QP encoding

Initial Comment:
If I send an email from Outlook to the listname-request address with this line:

subscribe address=test2 at ornl.gov

I get back the following result:

Your authorization is required for a mailing list subscription request
approval:

    For:  3Dtest2 at ornl.gov
...

Notice the "3D" in front of the original address.  It looks like Mailman isn't decoding the quoted-printable encoding before parsing the message body.

(Note: when I sent the message from Outlook, I forced it to "plain text")


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1829061&group_id=103

From noreply at sourceforge.net  Fri Nov  9 18:47:44 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Nov 2007 09:47:44 -0800
Subject: [ mailman-Bugs-1829061 ] Email subscribe interface and QP encoding
Message-ID: <E1IqXxI-0007RL-3J@sc8-sf-web23.sourceforge.net>

Bugs item #1829061, was opened at 2007-11-09 08:05
Message generated for change (Settings changed) made by msapiro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1829061&group_id=103

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: (un)subscribing
Group: 2.1 (stable)
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Larry Rosenbaum (lmr_ornl)
>Assigned to: Mark Sapiro (msapiro)
Summary: Email subscribe interface and QP encoding

Initial Comment:
If I send an email from Outlook to the listname-request address with this line:

subscribe address=test2 at ornl.gov

I get back the following result:

Your authorization is required for a mailing list subscription request
approval:

    For:  3Dtest2 at ornl.gov
...

Notice the "3D" in front of the original address.  It looks like Mailman isn't decoding the quoted-printable encoding before parsing the message body.

(Note: when I sent the message from Outlook, I forced it to "plain text")


----------------------------------------------------------------------

>Comment By: Mark Sapiro (msapiro)
Date: 2007-11-09 09:47

Message:
Logged In: YES 
user_id=1123998
Originator: NO

Fixed in 2.1.10b0

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1829061&group_id=103

From noreply at sourceforge.net  Fri Nov  9 21:19:42 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 09 Nov 2007 12:19:42 -0800
Subject: [ mailman-Bugs-1827247 ] add_members does not send welcome message
Message-ID: <E1IqaKM-0007dS-98@sc8-sf-web21.sourceforge.net>

Bugs item #1827247, was opened at 2007-11-07 01:08
Message generated for change (Comment added) made by thhart
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1827247&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: command line scripts
Group: 2.1 (stable)
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Thomas Hartwig (thhart)
Assigned to: Nobody/Anonymous (nobody)
Summary: add_members does not send welcome message

Initial Comment:
I use mailman with a CGI script wrapper to add subscribers via add_members. Subscribing succeeds but unfortunately it does not send out the welcome message nor the moderator information. Of course I have said so with the command all possible options, but nothing helps. Even from the console the messages will not be send.
remove_members has the same problem.

mailman: 2.1.9-8
system: Debian GNU/Linux testing (lenny)

----------------------------------------------------------------------

>Comment By: Thomas Hartwig (thhart)
Date: 2007-11-09 21:19

Message:
Logged In: YES 
user_id=57888
Originator: YES

Finally it was issued by an permission problem. "check_perms" showed somes
problems.


----------------------------------------------------------------------

Comment By: Mark Sapiro (msapiro)
Date: 2007-11-07 06:11

Message:
Logged In: YES 
user_id=1123998
Originator: NO

There was a bug in that if the list was set to not send welcome messages,
this could not be overridden in add_members or mass subscribe, but this was
fixed in 2.1.9.

I don't see this problem running add_mambers from the command line. I set
the list's send_welcome_message and admin_notify_mchanges off and run
'bin/add_members -r file -w y -a y listname' and the member in 'file'
received the welcome and the admin received the subscribe notice.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1827247&group_id=103

From noreply at sourceforge.net  Tue Nov 13 00:28:46 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 12 Nov 2007 15:28:46 -0800
Subject: [ mailman-Bugs-1242450 ] Scrubber URLs not properly delimited
Message-ID: <E1Irihy-00009T-23@sc8-sf-web21.sourceforge.net>

Bugs item #1242450, was opened at 2005-07-21 10:18
Message generated for change (Comment added) made by msapiro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1242450&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mail delivery
Group: 2.1 (stable)
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Ian Eiloart (ianeiloart)
Assigned to: Nobody/Anonymous (nobody)
Summary: Scrubber URLs not properly delimited

Initial Comment:
The URLs inserted by the scrubber are not properly delimited. I've 
seen instances where Apple Mail tried to fetch a URL like this, for 
example:

http://mail.sussex.ac.uk/mailman/private/iant-test5/attachments/
20050721/3533d8c6/
uscsbullet.png____________________________

Where the underscores came from the list signature.

Wrapping the URLs in angle brackets, in accordance with the 
recommendation of  the appendix of http://www.faqs.org/rfcs/
rfc1738.html fixes this problem. 

Here's a diff (-e) of Mailman/Handlers/Scrubber.py which seems to 
do the job:

313c
Url : <%(url)s>
.
280c
Url: <%(url)s>
.
259c
URL: <%(url)s>
.
233c
URL: <%(url)s>
.
205c
Url: <%(url)s>
.




----------------------------------------------------------------------

>Comment By: Mark Sapiro (msapiro)
Date: 2007-11-12 15:28

Message:
Logged In: YES 
user_id=1123998
Originator: NO

Fixed for 2.1.10.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1242450&group_id=103

From noreply at sourceforge.net  Tue Nov 13 01:01:53 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 12 Nov 2007 16:01:53 -0800
Subject: [ mailman-Bugs-963137 ] dumpdb broken
Message-ID: <E1IrjE1-0001TR-4x@sc8-sf-web23.sourceforge.net>

Bugs item #963137, was opened at 2004-05-30 07:12
Message generated for change (Comment added) made by msapiro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=963137&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: command line scripts
Group: 2.1 (stable)
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Paul Rubin (prubin)
Assigned to: Nobody/Anonymous (nobody)
Summary: dumpdb broken

Initial Comment:
In the stable 2.1.5 load dump db is broken:

Traceback (most recent call last):
  File "/var/mailman/bin/dumpdb", line 156, in ?
    msg = main()
  File "/var/mailman/bin/dumpdb", line 126, in main
    d = DumperSwitchboard().read(filename)
NameError: global name 'DumperSwitchboard' is not 
defined


----------------------------------------------------------------------

>Comment By: Mark Sapiro (msapiro)
Date: 2007-11-12 16:01

Message:
Logged In: YES 
user_id=1123998
Originator: NO

Fixed in 2.1.10.

----------------------------------------------------------------------

Comment By: Paul Rubin (prubin)
Date: 2004-05-30 20:33

Message:
Logged In: YES 
user_id=91557

Appearently, yo just removed support for .db files. it works 
fine on the .pck files...  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=963137&group_id=103

From noreply at sourceforge.net  Sat Nov 17 06:04:34 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 16 Nov 2007 21:04:34 -0800
Subject: [ mailman-Bugs-1833527 ] Fails to send own users mail to them.
Message-ID: <E1ItFr8-0004DJ-BH@sc8-sf-web21.sourceforge.net>

Bugs item #1833527, was opened at 2007-11-16 21:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1833527&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mail delivery
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tim Cook (twcook)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails to send own users mail to them.

Initial Comment:
In at least version 2.1.9, in at least two separate installations, I do not receive my own posts even though I ensured that the Yes option is selected. Another user on the same mailing list reported the same issue.

The only similarity I can find in our email addresses are that they are both quite long. 

timothywayne.cook at gmail.com

and 

serefarikan at kurumsalteknoloji.com




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1833527&group_id=103

From noreply at sourceforge.net  Sat Nov 17 07:05:30 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 16 Nov 2007 22:05:30 -0800
Subject: [ mailman-Bugs-1833527 ] Fails to send own users mail to them.
Message-ID: <E1ItGo6-0002QQ-BE@sc8-sf-web21.sourceforge.net>

Bugs item #1833527, was opened at 2007-11-16 21:04
Message generated for change (Comment added) made by msapiro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1833527&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mail delivery
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Tim Cook (twcook)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails to send own users mail to them.

Initial Comment:
In at least version 2.1.9, in at least two separate installations, I do not receive my own posts even though I ensured that the Yes option is selected. Another user on the same mailing list reported the same issue.

The only similarity I can find in our email addresses are that they are both quite long. 

timothywayne.cook at gmail.com

and 

serefarikan at kurumsalteknoloji.com




----------------------------------------------------------------------

>Comment By: Mark Sapiro (msapiro)
Date: 2007-11-16 22:05

Message:
Logged In: YES 
user_id=1123998
Originator: NO

I don't know what the issue is with serefarikan at kurumsalteknoloji.com, but
with timothywayne.cook at gmail.com, this is a gmail 'feature' that ignores
the post from the list because it is a duplicate of the message in Sent
Mail. This is a gmail issue and Mailman can't do anything about it.

This is noted at
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.042.htp> and
has been noted several times on mailman-users at python.org, e.g.,
<http://mail.python.org/pipermail/mailman-users/2005-February/042782.html>.

If you can provide more information about the issue with
serefarikan at kurumsalteknoloji.com, we can look into that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1833527&group_id=103

From noreply at sourceforge.net  Sat Nov 17 07:09:13 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri, 16 Nov 2007 22:09:13 -0800
Subject: [ mailman-Bugs-1833527 ] Fails to send own users mail to them.
Message-ID: <E1ItGrh-0002qr-72@sc8-sf-web21.sourceforge.net>

Bugs item #1833527, was opened at 2007-11-16 21:04
Message generated for change (Comment added) made by twcook
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1833527&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mail delivery
Group: 2.1 (stable)
>Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Tim Cook (twcook)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fails to send own users mail to them.

Initial Comment:
In at least version 2.1.9, in at least two separate installations, I do not receive my own posts even though I ensured that the Yes option is selected. Another user on the same mailing list reported the same issue.

The only similarity I can find in our email addresses are that they are both quite long. 

timothywayne.cook at gmail.com

and 

serefarikan at kurumsalteknoloji.com




----------------------------------------------------------------------

>Comment By: Tim Cook (twcook)
Date: 2007-11-16 22:09

Message:
Logged In: YES 
user_id=19267
Originator: YES

Thanks. Sorry I missed it in the mailing list archive.

----------------------------------------------------------------------

Comment By: Mark Sapiro (msapiro)
Date: 2007-11-16 22:05

Message:
Logged In: YES 
user_id=1123998
Originator: NO

I don't know what the issue is with serefarikan at kurumsalteknoloji.com, but
with timothywayne.cook at gmail.com, this is a gmail 'feature' that ignores
the post from the list because it is a duplicate of the message in Sent
Mail. This is a gmail issue and Mailman can't do anything about it.

This is noted at
<http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq03.042.htp> and
has been noted several times on mailman-users at python.org, e.g.,
<http://mail.python.org/pipermail/mailman-users/2005-February/042782.html>.

If you can provide more information about the issue with
serefarikan at kurumsalteknoloji.com, we can look into that.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1833527&group_id=103

From noreply at sourceforge.net  Sun Nov 18 19:32:09 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 18 Nov 2007 10:32:09 -0800
Subject: [ mailman-Patches-1220144 ] allow specifying another list in
	accept_these_nonmembers
Message-ID: <E1ItowD-0004vw-99@sc8-sf-web21.sourceforge.net>

Patches item #1220144, was opened at 2005-06-14 02:29
Message generated for change (Comment added) made by libertytrek
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1220144&group_id=103

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: list administration
Group: Mailman 2.2 / 3.0
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Jim Tittsler (jtittsler)
Assigned to: Tokio Kikuchi (tkikuchi)
Summary: allow specifying another list in accept_these_nonmembers

Initial Comment:
Add the capability to logically include the addresses
all of the members of another list in the same Mailman
installation to accept_these_nonmembers.

'@listname' checks the poster's address against the
membership of listname.


----------------------------------------------------------------------

Comment By: Charles (libertytrek)
Date: 2007-11-18 13:32

Message:
Logged In: YES 
user_id=1881071
Originator: NO

Hello,

I'm very interested in using this feature, but I'm not very good at adding
custom patches... any chance of an update on when this will be added to the
core code?

Thanks,

Charles

----------------------------------------------------------------------

Comment By: Tokio Kikuchi (tkikuchi)
Date: 2007-05-04 03:33

Message:
Logged In: YES 
user_id=67709
Originator: NO

Because '@' is mandatory in mailman 2.2 listname, I think that
'`listname at domain`' is more preferable.  Use of '`' is meaning 'evaluate
this list member'.

I also think we can merge this patch (along with the sibling list patch
#1347962) in the next mailman 2.1.10 because release of 2.2 is delayed
considerably.

Thoughts ?



----------------------------------------------------------------------

Comment By: Mark Sapiro (msapiro)
Date: 2006-12-01 15:30

Message:
Logged In: YES 
user_id=1123998
Originator: NO

The patch also applies without change to Mailman 2.1.9.

----------------------------------------------------------------------

Comment By: Mark Sapiro (msapiro)
Date: 2006-07-17 19:09

Message:
Logged In: YES 
user_id=1123998

The 2.1.6 patch also applies without change to Mailman 2.1.7
and 2.1.8. Even though there are minor changes in the
patched modules, the patched line numbers and the patch data
are unchanged.

----------------------------------------------------------------------

Comment By: Tokio Kikuchi (tkikuchi)
Date: 2005-11-17 21:37

Message:
Logged In: YES 
user_id=67709

Marking as an Mailman 2.2 new feature candidate.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1220144&group_id=103

From noreply at sourceforge.net  Sun Nov 18 20:58:54 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 18 Nov 2007 11:58:54 -0800
Subject: [ mailman-Patches-1220144 ] allow specifying another list in
	accept_these_nonmembers
Message-ID: <E1ItqIA-0005hR-7l@sc8-sf-web24.sourceforge.net>

Patches item #1220144, was opened at 2005-06-13 23:29
Message generated for change (Comment added) made by msapiro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1220144&group_id=103

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: list administration
Group: Mailman 2.2 / 3.0
Status: Open
Resolution: None
Priority: 6
Private: No
Submitted By: Jim Tittsler (jtittsler)
Assigned to: Tokio Kikuchi (tkikuchi)
Summary: allow specifying another list in accept_these_nonmembers

Initial Comment:
Add the capability to logically include the addresses
all of the members of another list in the same Mailman
installation to accept_these_nonmembers.

'@listname' checks the poster's address against the
membership of listname.


----------------------------------------------------------------------

>Comment By: Mark Sapiro (msapiro)
Date: 2007-11-18 11:58

Message:
Logged In: YES 
user_id=1123998
Originator: NO

Patch will be in 2.1.10.


----------------------------------------------------------------------

Comment By: Charles (libertytrek)
Date: 2007-11-18 10:32

Message:
Logged In: YES 
user_id=1881071
Originator: NO

Hello,

I'm very interested in using this feature, but I'm not very good at adding
custom patches... any chance of an update on when this will be added to the
core code?

Thanks,

Charles

----------------------------------------------------------------------

Comment By: Tokio Kikuchi (tkikuchi)
Date: 2007-05-04 00:33

Message:
Logged In: YES 
user_id=67709
Originator: NO

Because '@' is mandatory in mailman 2.2 listname, I think that
'`listname at domain`' is more preferable.  Use of '`' is meaning 'evaluate
this list member'.

I also think we can merge this patch (along with the sibling list patch
#1347962) in the next mailman 2.1.10 because release of 2.2 is delayed
considerably.

Thoughts ?



----------------------------------------------------------------------

Comment By: Mark Sapiro (msapiro)
Date: 2006-12-01 12:30

Message:
Logged In: YES 
user_id=1123998
Originator: NO

The patch also applies without change to Mailman 2.1.9.

----------------------------------------------------------------------

Comment By: Mark Sapiro (msapiro)
Date: 2006-07-17 16:09

Message:
Logged In: YES 
user_id=1123998

The 2.1.6 patch also applies without change to Mailman 2.1.7
and 2.1.8. Even though there are minor changes in the
patched modules, the patched line numbers and the patch data
are unchanged.

----------------------------------------------------------------------

Comment By: Tokio Kikuchi (tkikuchi)
Date: 2005-11-17 18:37

Message:
Logged In: YES 
user_id=67709

Marking as an Mailman 2.2 new feature candidate.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1220144&group_id=103

From noreply at sourceforge.net  Mon Nov 19 01:19:31 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun, 18 Nov 2007 16:19:31 -0800
Subject: [ mailman-Bugs-1834281 ] Wrong mailto subject/in-reply-to link in the
	article page
Message-ID: <E1ItuMN-0006IY-5G@sc8-sf-web22.sourceforge.net>

Bugs item #1834281, was opened at 2007-11-19 00:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1834281&group_id=103

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: 5
Private: No
Submitted By: Tokio Kikuchi (tkikuchi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong mailto subject/in-reply-to link in the article page

Initial Comment:
The Archived article page give an oppotunity to reply or to send comments with the mailto link on the poster (or the list address) with the subject and in-reply-to attributes set.  But, the subject should have the 'Re:' prefix like the other messages from the user's MUA, and 'In-Reply-To' should be the message-id of the article not the in-reply-to header value of it.

The patch is attached.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1834281&group_id=103

From noreply at sourceforge.net  Mon Nov 19 15:48:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Nov 2007 06:48:43 -0800
Subject: [ mailman-Bugs-1834569 ] core dump when list admin is set to be the
	list bounce addr
Message-ID: <E1Iu7vX-0005RQ-7e@sc8-sf-web21.sourceforge.net>

Bugs item #1834569, was opened at 2007-11-19 15:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1834569&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mail delivery
Group: 2.0.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: gjmurphy (gjmurphy)
Assigned to: Nobody/Anonymous (nobody)
Summary: core dump when list admin is set to be the list bounce addr

Initial Comment:
A list manager here decided that the list admin email address should be set to the list bounce address. 

Later, a message was sent to this address informing the admin that there were requests pending approval/whatever.  Mailman then accepted this message and attempted to parse it as a bounce message which, obviously, failed.  This failure was then send to the list administrator informing them that a bounce message could not be parsed.  This was repeated until python coredumped the bounce queuerunner process.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1834569&group_id=103

From noreply at sourceforge.net  Mon Nov 19 21:38:16 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon, 19 Nov 2007 12:38:16 -0800
Subject: [ mailman-Bugs-1834569 ] core dump when list admin is set to be the
	list bounce addr
Message-ID: <E1IuDNo-0001qG-1j@sc8-sf-web22.sourceforge.net>

Bugs item #1834569, was opened at 2007-11-19 06:48
Message generated for change (Settings changed) made by msapiro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1834569&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mail delivery
Group: 2.0.x
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: gjmurphy (gjmurphy)
Assigned to: Nobody/Anonymous (nobody)
Summary: core dump when list admin is set to be the list bounce addr

Initial Comment:
A list manager here decided that the list admin email address should be set to the list bounce address. 

Later, a message was sent to this address informing the admin that there were requests pending approval/whatever.  Mailman then accepted this message and attempted to parse it as a bounce message which, obviously, failed.  This failure was then send to the list administrator informing them that a bounce message could not be parsed.  This was repeated until python coredumped the bounce queuerunner process.

----------------------------------------------------------------------

>Comment By: Mark Sapiro (msapiro)
Date: 2007-11-19 12:38

Message:
Logged In: YES 
user_id=1123998
Originator: NO

Fixed in Mailman 2.1.10.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1834569&group_id=103

From noreply at sourceforge.net  Tue Nov 27 22:19:43 2007
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue, 27 Nov 2007 13:19:43 -0800
Subject: [ mailman-Bugs-1834569 ] core dump when list admin is set to be the
	list bounce addr
Message-ID: <E1Ix7qJ-00024u-5t@sc8-sf-web22.sourceforge.net>

Bugs item #1834569, was opened at 2007-11-19 15:48
Message generated for change (Settings changed) made by gjmurphy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1834569&group_id=103

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mail delivery
Group: 2.0.x
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: gjmurphy (gjmurphy)
Assigned to: Nobody/Anonymous (nobody)
Summary: core dump when list admin is set to be the list bounce addr

Initial Comment:
A list manager here decided that the list admin email address should be set to the list bounce address. 

Later, a message was sent to this address informing the admin that there were requests pending approval/whatever.  Mailman then accepted this message and attempted to parse it as a bounce message which, obviously, failed.  This failure was then send to the list administrator informing them that a bounce message could not be parsed.  This was repeated until python coredumped the bounce queuerunner process.

----------------------------------------------------------------------

Comment By: Mark Sapiro (msapiro)
Date: 2007-11-19 21:38

Message:
Logged In: YES 
user_id=1123998
Originator: NO

Fixed in Mailman 2.1.10.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1834569&group_id=103