From noreply at sourceforge.net Wed Nov 1 15:21:09 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 06:21:09 -0800 Subject: [ mailman-Bugs-1588617 ] Mistake in french translation Message-ID: Bugs item #1588617, was opened at 2006-11-01 15:21 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=1588617&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: Maxime Carron (Pingoomax) (pingoomax) Assigned to: Nobody/Anonymous (nobody) Summary: Mistake in french translation Initial Comment: I changed my email address on a mailing-list powered by mailman. Here is the text displayed, when I click on the link received in the confirmation email. ------------- Confirmez la requ?te de changement d'adresse Votre confirmation est n?cessaire pour achever le processus de changement d'adresse pour la liste fedora-fr-doc. Vous ?tes actuellement abonn? avec comme * Nom Complet: Maxime CARRON * Adresse Courriel: *******@*****.com et vous avez demand? un de votre adresse courriel vers * Nouvelle Adresse Courriel: ******@******.com Cliquez sur le bouton Changer l'adresse ci-dessous pour achever le processus de confirmation. Ou cliquez sur Annuler et ignorer pour annuler cette requ?te de changement d'adresse. -------------------- "et vous avez demand? un de votre adresse courriel..." should be : "et vous avez demand? un **changement** de votre adresse courriel" VERSION FRANCAISE : (ca sera plus clair) Il manque un mot dans une phrase (cf ci-dessus). Cette page est affich?e lorsque l'on clique sur le lien envoy? dans le mail de confirmation, recu apres une demande de changement d'adresse mail. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1588617&group_id=103 From noreply at sourceforge.net Thu Nov 2 05:30:04 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 01 Nov 2006 20:30:04 -0800 Subject: [ mailman-Patches-1589056 ] list only lists from the requested domain Message-ID: Patches item #1589056, was opened at 2006-11-01 23:30 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1589056&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.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: The Anarcat (anarcat) Assigned to: Nobody/Anonymous (nobody) Summary: list only lists from the requested domain Initial Comment: In Mailman 2.1, the listinfo page lists all pages belonging to the current vhost. Or not exactly. It lists all lists that have the current vhost in their web_page_url. Which is wrong, because if I have a list like list at sub.example.com and visit http://example.com/mailman/listinfo, it *will* be listed. I would expect it to be listed only if I visit http://sub.example.com/mailman/listinfo. This one-line patch fixes this. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1589056&group_id=103 From noreply at sourceforge.net Sat Nov 11 11:34:10 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 02:34:10 -0800 Subject: [ mailman-Feature Requests-673265 ] Post confirmation + moderation Message-ID: Feature Requests item #673265, was opened at 2003-01-23 18:39 Message generated for change (Comment added) made by lnu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=673265&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: Samuel Tardieu (samtardieu) Assigned to: Nobody/Anonymous (nobody) Summary: Post confirmation + moderation Initial Comment: The following scheme (implemented by me for Sympa as a scenario some time ago) leads to a spam-free mailing-list with almost no work from the moderator. When a mail arrive and should be held for any reason (sender not in subscriber list, list not in to: or cc:, too many recipients), ask the alleged sender to confirm its post then hold it for moderation when the sender confirms its intention to post. This way, spam (whose confirmation request will almost never be answered) is not presented to the moderators, while mail sent by humans will. It would be great to have this feature in mailman. ---------------------------------------------------------------------- Comment By: Lucas Nussbaum (lnu) Date: 2006-11-11 10:34 Message: Logged In: YES user_id=527142 Hi, This feature would really be great to have in mailman. Additionnally, a web-based confirmation interface could be added, with an image-based confirmation, to prevent robots from auto-confirming their posts. Is it planned ? I'm a bit concerned by the fact that this feature request was posted more than 3 years ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=673265&group_id=103 From noreply at sourceforge.net Sat Nov 11 11:52:13 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sat, 11 Nov 2006 02:52:13 -0800 Subject: [ mailman-Feature Requests-673265 ] Post confirmation + moderation Message-ID: Feature Requests item #673265, was opened at 2003-01-23 18:39 Message generated for change (Comment added) made by lnu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=673265&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: Samuel Tardieu (samtardieu) Assigned to: Nobody/Anonymous (nobody) Summary: Post confirmation + moderation Initial Comment: The following scheme (implemented by me for Sympa as a scenario some time ago) leads to a spam-free mailing-list with almost no work from the moderator. When a mail arrive and should be held for any reason (sender not in subscriber list, list not in to: or cc:, too many recipients), ask the alleged sender to confirm its post then hold it for moderation when the sender confirms its intention to post. This way, spam (whose confirmation request will almost never be answered) is not presented to the moderators, while mail sent by humans will. It would be great to have this feature in mailman. ---------------------------------------------------------------------- Comment By: Lucas Nussbaum (lnu) Date: 2006-11-11 10:52 Message: Logged In: YES user_id=527142 Also, this could be implemented in a greylist-like way: the sender would have to confirm his first post, and then, its mails would get auto-accepted for a few hours/days. ---------------------------------------------------------------------- Comment By: Lucas Nussbaum (lnu) Date: 2006-11-11 10:34 Message: Logged In: YES user_id=527142 Hi, This feature would really be great to have in mailman. Additionnally, a web-based confirmation interface could be added, with an image-based confirmation, to prevent robots from auto-confirming their posts. Is it planned ? I'm a bit concerned by the fact that this feature request was posted more than 3 years ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=673265&group_id=103 From noreply at sourceforge.net Mon Nov 13 03:48:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 12 Nov 2006 18:48:39 -0800 Subject: [ mailman-Feature Requests-673265 ] Post confirmation + moderation Message-ID: Feature Requests item #673265, was opened at 2003-01-24 02:39 Message generated for change (Comment added) made by watha You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=673265&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: Samuel Tardieu (samtardieu) Assigned to: Nobody/Anonymous (nobody) Summary: Post confirmation + moderation Initial Comment: The following scheme (implemented by me for Sympa as a scenario some time ago) leads to a spam-free mailing-list with almost no work from the moderator. When a mail arrive and should be held for any reason (sender not in subscriber list, list not in to: or cc:, too many recipients), ask the alleged sender to confirm its post then hold it for moderation when the sender confirms its intention to post. This way, spam (whose confirmation request will almost never be answered) is not presented to the moderators, while mail sent by humans will. It would be great to have this feature in mailman. ---------------------------------------------------------------------- Comment By: James Andrewartha (watha) Date: 2006-11-13 10:48 Message: Logged In: YES user_id=460267 http://viewmtn.angrygoats.net/revision/diff/dfedaca2816739f4f052d21247f6877f5ee39905/with/c6835f6646f467e9a012823b0817e17e152f9811 has an implementation for this, although there's a few other features mixed into the diff as well. ---------------------------------------------------------------------- Comment By: Lucas Nussbaum (lnu) Date: 2006-11-11 18:52 Message: Logged In: YES user_id=527142 Also, this could be implemented in a greylist-like way: the sender would have to confirm his first post, and then, its mails would get auto-accepted for a few hours/days. ---------------------------------------------------------------------- Comment By: Lucas Nussbaum (lnu) Date: 2006-11-11 18:34 Message: Logged In: YES user_id=527142 Hi, This feature would really be great to have in mailman. Additionnally, a web-based confirmation interface could be added, with an image-based confirmation, to prevent robots from auto-confirming their posts. Is it planned ? I'm a bit concerned by the fact that this feature request was posted more than 3 years ago. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=673265&group_id=103 From noreply at sourceforge.net Fri Nov 17 00:55:44 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 15:55:44 -0800 Subject: [ mailman-Bugs-1598087 ] Error mail may be accumulated in qfiles Message-ID: Bugs item #1598087, was opened at 2006-11-16 23:55 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=1598087&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: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Error mail may be accumulated in qfiles Initial Comment: Mailman/Queue/Runner.py is called by other runners and resposible for dequeueing from one queue and enqueue into another after processing. In _oneloop() function it shunts error messages during processing but leaves them in the original queue directory by noting 'Ignoring ...' message in the error log. These left errorneous messages are never treated again and may be accumulated and slow down the queue processing. These messages should be shunted also. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1598087&group_id=103 From noreply at sourceforge.net Fri Nov 17 06:36:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 16 Nov 2006 21:36:15 -0800 Subject: [ mailman-Bugs-1598087 ] Error mail may be accumulated in qfiles Message-ID: Bugs item #1598087, was opened at 2006-11-16 15:55 Message generated for change (Comment added) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1598087&group_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: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: Error mail may be accumulated in qfiles Initial Comment: Mailman/Queue/Runner.py is called by other runners and resposible for dequeueing from one queue and enqueue into another after processing. In _oneloop() function it shunts error messages during processing but leaves them in the original queue directory by noting 'Ignoring ...' message in the error log. These left errorneous messages are never treated again and may be accumulated and slow down the queue processing. These messages should be shunted also. ---------------------------------------------------------------------- >Comment By: Mark Sapiro (msapiro) Date: 2006-11-16 21:36 Message: Logged In: YES user_id=1123998 Originator: NO If I understand the issue correctly, the problem is that the .bak file is left in the original queue after the parse error. This is not a recoverable error as explained in the code comment, thus I don't think the proper action is to shunt the message. Rather, I think the proper action is to continue to log the event and just remove the .bak file. Not removing the .bak file was an oversight in the original backup implementation. My suggested patch is attached. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1598087&group_id=103 From noreply at sourceforge.net Wed Nov 22 19:23:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 22 Nov 2006 10:23:37 -0800 Subject: [ mailman-Bugs-1601302 ] no confirm if not necessary Message-ID: Bugs item #1601302, was opened at 2006-11-22 13:23 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=1601302&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: Full Decent (fulldecent) Assigned to: Nobody/Anonymous (nobody) Summary: no confirm if not necessary Initial Comment: If I enter my email address and password, then click unsubscribe, that should be the end of it - no email confirmation required. A confirmation should only be required when I do not have my password. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1601302&group_id=103 From noreply at sourceforge.net Sun Nov 26 20:23:45 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 11:23:45 -0800 Subject: [ mailman-Bugs-209499 ] Security hole: passwords mailed in clear Message-ID: Bugs item #209499, was opened at 2000-07-14 15:26 Message generated for change (Comment added) made by bburkhart You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=209499&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: Closed Resolution: Wont Fix Priority: 5 Private: No Submitted By: L. Peter Deutsch (lpd) Assigned to: Nobody/Anonymous (nobody) Summary: Security hole: passwords mailed in clear Initial Comment: I recently signed up on a SourceForge mailing list. The software mailed a confirmation notice to my mailbox, with the password in clear in the message. This is a basic security hole. I reported this as a SourceForge bug, and they said "Contact the gnu-mailman project." In my opinion, passwords should never be mailed in clear, especially not to the e-mail address with which they are associated. Please consider changing this. ---------------------------------------------------------------------- Comment By: Benjamin Bl?mchen (bburkhart) Date: 2006-11-27 08:23 Message: Logged In: YES user_id=597317 Originator: NO Hello everyone, to me, mailing passwords in clear text is never acceptable. In some setups. one never knows who else is looking at the mail. The lack of biological RAM in layer 8 is also not an excuse. There are better ways of dealing with the password remembering problem. Anyway, mailman is now out of question and also uninstalled from my machine. Cheers Benjamin ---------------------------------------------------------------------- Comment By: L. Peter Deutsch (lpd) Date: 2000-07-24 18:31 Message: It's OK with me if you want to close this report; in my opinion, the Resolution should say "Wont fix". ---------------------------------------------------------------------- Comment By: Thomas Wouters (twouters) Date: 2000-07-17 21:43 Message: The Mailman password is in no way a secure password. Mailman is intended for a wide variety of users, most of which are unable to remember even the simplest password ;) The Mailman password is not used as an authentication method, but more as a *confirmation* method. You'll get a password reminder every month or so (if the list admin and site admin enabled that) and the only thing you use the password for are for unsubscribing, changing your options and viewing the private archive (if any.) In future versions of Mailman it might be possible to use external passwords for mailinglist subscribers, but currently the infrastructure for that is missing. It's on the TODO list, in any case :) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=209499&group_id=103 From noreply at sourceforge.net Mon Nov 27 00:09:19 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Sun, 26 Nov 2006 15:09:19 -0800 Subject: [ mailman-Bugs-1603400 ] difficult to discard spam postings via e-mail Message-ID: Bugs item #1603400, was opened at 2006-11-27 01:09 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=1603400&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: Paul Pogonyshev (doublep) Assigned to: Nobody/Anonymous (nobody) Summary: difficult to discard spam postings via e-mail Initial Comment: In notifications about spam-posting to my project's mailing list, this is written: If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. Natural reflex is to hit R (reply) to reply to the whole message. This doesn't work... This text comes in an encapsulated message and it is difficult to reply to an encapsulated message (at least in KMail: you need to right-click "encapsulated message" text, choose view, then reply, and then close the view window.) It would be simpler if just replying to the message you get worked for discarding spam, without all the additional moves. (I posted this to Savane first, but they redirected me here.) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1603400&group_id=103 From noreply at sourceforge.net Wed Nov 29 11:28:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 02:28:50 -0800 Subject: [ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers Message-ID: Bugs item #1605144, was opened at 2006-11-29 10:28 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=1605144&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: David Woodhouse (dwmw2) Assigned to: Nobody/Anonymous (nobody) Summary: mailman corrupts RFC2047-encoded headers Initial Comment: Given an input like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup,=20fix=20ECC=20on=20reading=20empty=20flash?= Mailman appears to emit mail like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup, =20fix=20ECC=20on=20reading=20empty=20flash?= The input was RFC2047-compliant. The output isn't. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&group_id=103 From noreply at sourceforge.net Wed Nov 29 11:44:25 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 02:44:25 -0800 Subject: [ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers Message-ID: Bugs item #1605144, was opened at 2006-11-29 11:28 Message generated for change (Comment added) made by saturn_de You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&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: David Woodhouse (dwmw2) Assigned to: Nobody/Anonymous (nobody) Summary: mailman corrupts RFC2047-encoded headers Initial Comment: Given an input like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup,=20fix=20ECC=20on=20reading=20empty=20flash?= Mailman appears to emit mail like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup, =20fix=20ECC=20on=20reading=20empty=20flash?= The input was RFC2047-compliant. The output isn't. ---------------------------------------------------------------------- Comment By: Harald Hoyer (Red Hat) (saturn_de) Date: 2006-11-29 11:44 Message: Logged In: YES user_id=5540 Originator: NO http://www.ietf.org/rfc/rfc2047.txt An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&group_id=103 From noreply at sourceforge.net Wed Nov 29 12:53:26 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 03:53:26 -0800 Subject: [ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers Message-ID: Bugs item #1605144, was opened at 2006-11-29 10:28 Message generated for change (Comment added) made by dwmw2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&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: David Woodhouse (dwmw2) Assigned to: Nobody/Anonymous (nobody) Summary: mailman corrupts RFC2047-encoded headers Initial Comment: Given an input like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup,=20fix=20ECC=20on=20reading=20empty=20flash?= Mailman appears to emit mail like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup, =20fix=20ECC=20on=20reading=20empty=20flash?= The input was RFC2047-compliant. The output isn't. ---------------------------------------------------------------------- >Comment By: David Woodhouse (dwmw2) Date: 2006-11-29 11:53 Message: Logged In: YES user_id=81423 Originator: YES Hm, good point; thanks. I've fixed the script which generates mail for each commit to the Linux kernel git tree, and it should no longer generate encoded-words longer than 75 characters. I still see this input... Subject: =?UTF-8?Q?[MTD]_NAND:_CAF=C3=89_NAND_driver_cleanup,_fix_ECC_on_reading?= =?UTF-8?Q?_empty_flash?= and this output... Subject: =?UTF-8?Q?[MTD]_NAND:_CAF=C3=89_NAND_driver_cleanup, _fix_ECC_on_reading?= =?UTF-8?Q?_empty_flash?= The comma is allowed, and doesn't have to be '=2C', does it? See ?4.2 (3) and ?5 (1). ---------------------------------------------------------------------- Comment By: Harald Hoyer (Red Hat) (saturn_de) Date: 2006-11-29 10:44 Message: Logged In: YES user_id=5540 Originator: NO http://www.ietf.org/rfc/rfc2047.txt An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&group_id=103 From noreply at sourceforge.net Wed Nov 29 13:21:39 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 04:21:39 -0800 Subject: [ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers Message-ID: Bugs item #1605144, was opened at 2006-11-29 11:28 Message generated for change (Comment added) made by saturn_de You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&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: David Woodhouse (dwmw2) Assigned to: Nobody/Anonymous (nobody) Summary: mailman corrupts RFC2047-encoded headers Initial Comment: Given an input like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup,=20fix=20ECC=20on=20reading=20empty=20flash?= Mailman appears to emit mail like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup, =20fix=20ECC=20on=20reading=20empty=20flash?= The input was RFC2047-compliant. The output isn't. ---------------------------------------------------------------------- Comment By: Harald Hoyer (Red Hat) (saturn_de) Date: 2006-11-29 13:21 Message: Logged In: YES user_id=5540 Originator: NO Hmm, I don't thin "," is allowed unencoded... token = 1* especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" ---------------------------------------------------------------------- Comment By: David Woodhouse (dwmw2) Date: 2006-11-29 12:53 Message: Logged In: YES user_id=81423 Originator: YES Hm, good point; thanks. I've fixed the script which generates mail for each commit to the Linux kernel git tree, and it should no longer generate encoded-words longer than 75 characters. I still see this input... Subject: =?UTF-8?Q?[MTD]_NAND:_CAF=C3=89_NAND_driver_cleanup,_fix_ECC_on_reading?= =?UTF-8?Q?_empty_flash?= and this output... Subject: =?UTF-8?Q?[MTD]_NAND:_CAF=C3=89_NAND_driver_cleanup, _fix_ECC_on_reading?= =?UTF-8?Q?_empty_flash?= The comma is allowed, and doesn't have to be '=2C', does it? See ?4.2 (3) and ?5 (1). ---------------------------------------------------------------------- Comment By: Harald Hoyer (Red Hat) (saturn_de) Date: 2006-11-29 11:44 Message: Logged In: YES user_id=5540 Originator: NO http://www.ietf.org/rfc/rfc2047.txt An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&group_id=103 From noreply at sourceforge.net Wed Nov 29 14:15:37 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 05:15:37 -0800 Subject: [ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers Message-ID: Bugs item #1605144, was opened at 2006-11-29 10:28 Message generated for change (Comment added) made by dwmw2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&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: David Woodhouse (dwmw2) Assigned to: Nobody/Anonymous (nobody) Summary: mailman corrupts RFC2047-encoded headers Initial Comment: Given an input like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup,=20fix=20ECC=20on=20reading=20empty=20flash?= Mailman appears to emit mail like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup, =20fix=20ECC=20on=20reading=20empty=20flash?= The input was RFC2047-compliant. The output isn't. ---------------------------------------------------------------------- >Comment By: David Woodhouse (dwmw2) Date: 2006-11-29 13:15 Message: Logged In: YES user_id=81423 Originator: YES That's only for the charset (UTF-8) and the encoding (Q). The comma appears in the encoded-text, and should be fine (since this is a Subject: header and hence comes under paragraph (1) of ?5. encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" charset = token ; see section 3 encoding = token ; see section 4 token = 1* especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" encoded-text = 1* ; (but see "Use of encoded-words in message ; headers", section 5) ---------------------------------------------------------------------- Comment By: Harald Hoyer (Red Hat) (saturn_de) Date: 2006-11-29 12:21 Message: Logged In: YES user_id=5540 Originator: NO Hmm, I don't thin "," is allowed unencoded... token = 1* especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" ---------------------------------------------------------------------- Comment By: David Woodhouse (dwmw2) Date: 2006-11-29 11:53 Message: Logged In: YES user_id=81423 Originator: YES Hm, good point; thanks. I've fixed the script which generates mail for each commit to the Linux kernel git tree, and it should no longer generate encoded-words longer than 75 characters. I still see this input... Subject: =?UTF-8?Q?[MTD]_NAND:_CAF=C3=89_NAND_driver_cleanup,_fix_ECC_on_reading?= =?UTF-8?Q?_empty_flash?= and this output... Subject: =?UTF-8?Q?[MTD]_NAND:_CAF=C3=89_NAND_driver_cleanup, _fix_ECC_on_reading?= =?UTF-8?Q?_empty_flash?= The comma is allowed, and doesn't have to be '=2C', does it? See ?4.2 (3) and ?5 (1). ---------------------------------------------------------------------- Comment By: Harald Hoyer (Red Hat) (saturn_de) Date: 2006-11-29 10:44 Message: Logged In: YES user_id=5540 Originator: NO http://www.ietf.org/rfc/rfc2047.txt An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&group_id=103 From noreply at sourceforge.net Wed Nov 29 14:46:46 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 05:46:46 -0800 Subject: [ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers Message-ID: Bugs item #1605144, was opened at 2006-11-29 11:28 Message generated for change (Comment added) made by saturn_de You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&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: David Woodhouse (dwmw2) Assigned to: Nobody/Anonymous (nobody) Summary: mailman corrupts RFC2047-encoded headers Initial Comment: Given an input like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup,=20fix=20ECC=20on=20reading=20empty=20flash?= Mailman appears to emit mail like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup, =20fix=20ECC=20on=20reading=20empty=20flash?= The input was RFC2047-compliant. The output isn't. ---------------------------------------------------------------------- Comment By: Harald Hoyer (Red Hat) (saturn_de) Date: 2006-11-29 14:46 Message: Logged In: YES user_id=5540 Originator: NO Hmm, my thunderbird encodes "," with =2C ---------------------------------------------------------------------- Comment By: David Woodhouse (dwmw2) Date: 2006-11-29 14:15 Message: Logged In: YES user_id=81423 Originator: YES That's only for the charset (UTF-8) and the encoding (Q). The comma appears in the encoded-text, and should be fine (since this is a Subject: header and hence comes under paragraph (1) of ?5. encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" charset = token ; see section 3 encoding = token ; see section 4 token = 1* especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" encoded-text = 1* ; (but see "Use of encoded-words in message ; headers", section 5) ---------------------------------------------------------------------- Comment By: Harald Hoyer (Red Hat) (saturn_de) Date: 2006-11-29 13:21 Message: Logged In: YES user_id=5540 Originator: NO Hmm, I don't thin "," is allowed unencoded... token = 1* especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" ---------------------------------------------------------------------- Comment By: David Woodhouse (dwmw2) Date: 2006-11-29 12:53 Message: Logged In: YES user_id=81423 Originator: YES Hm, good point; thanks. I've fixed the script which generates mail for each commit to the Linux kernel git tree, and it should no longer generate encoded-words longer than 75 characters. I still see this input... Subject: =?UTF-8?Q?[MTD]_NAND:_CAF=C3=89_NAND_driver_cleanup,_fix_ECC_on_reading?= =?UTF-8?Q?_empty_flash?= and this output... Subject: =?UTF-8?Q?[MTD]_NAND:_CAF=C3=89_NAND_driver_cleanup, _fix_ECC_on_reading?= =?UTF-8?Q?_empty_flash?= The comma is allowed, and doesn't have to be '=2C', does it? See ?4.2 (3) and ?5 (1). ---------------------------------------------------------------------- Comment By: Harald Hoyer (Red Hat) (saturn_de) Date: 2006-11-29 11:44 Message: Logged In: YES user_id=5540 Originator: NO http://www.ietf.org/rfc/rfc2047.txt An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&group_id=103 From noreply at sourceforge.net Wed Nov 29 15:00:15 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 06:00:15 -0800 Subject: [ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers Message-ID: Bugs item #1605144, was opened at 2006-11-29 10:28 Message generated for change (Comment added) made by dwmw2 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&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: David Woodhouse (dwmw2) Assigned to: Nobody/Anonymous (nobody) Summary: mailman corrupts RFC2047-encoded headers Initial Comment: Given an input like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup,=20fix=20ECC=20on=20reading=20empty=20flash?= Mailman appears to emit mail like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup, =20fix=20ECC=20on=20reading=20empty=20flash?= The input was RFC2047-compliant. The output isn't. ---------------------------------------------------------------------- >Comment By: David Woodhouse (dwmw2) Date: 2006-11-29 14:00 Message: Logged In: YES user_id=81423 Originator: YES Your thunderbird also refuses to send this: To: Some people : ; Bcc: foo at bar.org, baz at turnip.com Thunderbird isn't necessarily the best test of what's valid :) The pertinent question is: why is mailman munging this _anyway_? Why can't it just pass the header through as it was originally sent? If I put line breaks in and lined things up sensibly like a SpamAssassin report does, why should that be mangled by mailman? ---------------------------------------------------------------------- Comment By: Harald Hoyer (Red Hat) (saturn_de) Date: 2006-11-29 13:46 Message: Logged In: YES user_id=5540 Originator: NO Hmm, my thunderbird encodes "," with =2C ---------------------------------------------------------------------- Comment By: David Woodhouse (dwmw2) Date: 2006-11-29 13:15 Message: Logged In: YES user_id=81423 Originator: YES That's only for the charset (UTF-8) and the encoding (Q). The comma appears in the encoded-text, and should be fine (since this is a Subject: header and hence comes under paragraph (1) of ?5. encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" charset = token ; see section 3 encoding = token ; see section 4 token = 1* especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" encoded-text = 1* ; (but see "Use of encoded-words in message ; headers", section 5) ---------------------------------------------------------------------- Comment By: Harald Hoyer (Red Hat) (saturn_de) Date: 2006-11-29 12:21 Message: Logged In: YES user_id=5540 Originator: NO Hmm, I don't thin "," is allowed unencoded... token = 1* especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" ---------------------------------------------------------------------- Comment By: David Woodhouse (dwmw2) Date: 2006-11-29 11:53 Message: Logged In: YES user_id=81423 Originator: YES Hm, good point; thanks. I've fixed the script which generates mail for each commit to the Linux kernel git tree, and it should no longer generate encoded-words longer than 75 characters. I still see this input... Subject: =?UTF-8?Q?[MTD]_NAND:_CAF=C3=89_NAND_driver_cleanup,_fix_ECC_on_reading?= =?UTF-8?Q?_empty_flash?= and this output... Subject: =?UTF-8?Q?[MTD]_NAND:_CAF=C3=89_NAND_driver_cleanup, _fix_ECC_on_reading?= =?UTF-8?Q?_empty_flash?= The comma is allowed, and doesn't have to be '=2C', does it? See ?4.2 (3) and ?5 (1). ---------------------------------------------------------------------- Comment By: Harald Hoyer (Red Hat) (saturn_de) Date: 2006-11-29 10:44 Message: Logged In: YES user_id=5540 Originator: NO http://www.ietf.org/rfc/rfc2047.txt An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&group_id=103 From noreply at sourceforge.net Wed Nov 29 15:41:34 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 06:41:34 -0800 Subject: [ mailman-Feature Requests-1074197 ] Web interface to sync_members Message-ID: Feature Requests item #1074197, was opened at 2004-11-27 14:53 Message generated for change (Comment added) made by hildeb You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1074197&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: Matthew Saltzman (cumthsc) Assigned to: Nobody/Anonymous (nobody) Summary: Web interface to sync_members Initial Comment: It would be useful to extend the Membership Management page to support sync_members. We use mailman to run a number of members-only lists for a professional society. The membership database is kept on a separate system, and lists of current members are produced for the various lists at regular intervals. It would be easier for our non-technical office staff to keep the mailing list memberships in sync with the main database if they could upload the member list through the Web rather than having to upload the file with FTP and use sudo and shell commands to do the synching. We could mass-delete and mass-subscribe, but it would be more convenient to do it in one step. Also, for some of the lists, new members should receive notification that they have been subscribed, but carry-over members should not get such notification. The only way to do that with add_members is to add in two steps or to make two files with members to be deleted and members to be added, leaving the carry-over members subscribed. ---------------------------------------------------------------------- Comment By: Ralf Hildebrandt (hildeb) Date: 2006-11-29 15:41 Message: Logged In: YES user_id=77128 Originator: NO I implemented that feature. How can I upload a patch against 2.1.9? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=350103&aid=1074197&group_id=103 From noreply at sourceforge.net Wed Nov 29 15:47:50 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Wed, 29 Nov 2006 06:47:50 -0800 Subject: [ mailman-Patches-1605292 ] patch to add sync_members functionality to the Web UI Message-ID: Patches item #1605292, was opened at 2006-11-29 15:47 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1605292&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: Web UI Group: Mailman 2.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ralf Hildebrandt (hildeb) Assigned to: Nobody/Anonymous (nobody) Summary: patch to add sync_members functionality to the Web UI Initial Comment: The ugly patch is made of two parts: * Part one adds the "sync" option on the Membership page * Part two is the dirty work. admin.py is patched to implement the function mass_sync Stuff like notifications has been blissfully omitted. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=1605292&group_id=103 From noreply at sourceforge.net Thu Nov 30 13:46:51 2006 From: noreply at sourceforge.net (SourceForge.net) Date: Thu, 30 Nov 2006 04:46:51 -0800 Subject: [ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers Message-ID: Bugs item #1605144, was opened at 2006-11-29 10:28 Message generated for change (Comment added) made by tkikuchi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&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: David Woodhouse (dwmw2) Assigned to: Nobody/Anonymous (nobody) Summary: mailman corrupts RFC2047-encoded headers Initial Comment: Given an input like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup,=20fix=20ECC=20on=20reading=20empty=20flash?= Mailman appears to emit mail like this: Subject: =?UTF-8?Q?[MTD]=20NAND:=20CAF=C3=89=20NAND=20driver=20cleanup, =20fix=20ECC=20on=20reading=20empty=20flash?= The input was RFC2047-compliant. The output isn't. ---------------------------------------------------------------------- >Comment By: Tokio Kikuchi (tkikuchi) Date: 2006-11-30 12:46 Message: Logged In: YES user_id=67709 Originator: NO This is derived from the python email module behavior that try to keep a header line within 78 characters. Mailman parses the message first and do something like adding subject prefix or message body header/footer then regenerate RFC-2822 message. Email module thinks your subject has two part structure separated by a comma and split by CRLF. I am not very sure but current version of email doesn't distinguish structured and unstructured headers defined in 2.2.1 and 2.2.2 of RFC-2822. Anyway, It is safer to shorten the header lines within 78 charcters. FYI, email module generates your subject header like this: Subject: =?utf-8?q?=5BMTD=5D_NAND=3A_CAF=C3=89_NAND_driver_cleanup=2C_fix?= =?utf-8?q?_ECC_on_reading_empty_flash?= ---------------------------------------------------------------------- Comment By: David Woodhouse (dwmw2) Date: 2006-11-29 14:00 Message: Logged In: YES user_id=81423 Originator: YES Your thunderbird also refuses to send this: To: Some people : ; Bcc: foo at bar.org, baz at turnip.com Thunderbird isn't necessarily the best test of what's valid :) The pertinent question is: why is mailman munging this _anyway_? Why can't it just pass the header through as it was originally sent? If I put line breaks in and lined things up sensibly like a SpamAssassin report does, why should that be mangled by mailman? ---------------------------------------------------------------------- Comment By: Harald Hoyer (Red Hat) (saturn_de) Date: 2006-11-29 13:46 Message: Logged In: YES user_id=5540 Originator: NO Hmm, my thunderbird encodes "," with =2C ---------------------------------------------------------------------- Comment By: David Woodhouse (dwmw2) Date: 2006-11-29 13:15 Message: Logged In: YES user_id=81423 Originator: YES That's only for the charset (UTF-8) and the encoding (Q). The comma appears in the encoded-text, and should be fine (since this is a Subject: header and hence comes under paragraph (1) of ?5. encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" charset = token ; see section 3 encoding = token ; see section 4 token = 1* especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" encoded-text = 1* ; (but see "Use of encoded-words in message ; headers", section 5) ---------------------------------------------------------------------- Comment By: Harald Hoyer (Red Hat) (saturn_de) Date: 2006-11-29 12:21 Message: Logged In: YES user_id=5540 Originator: NO Hmm, I don't thin "," is allowed unencoded... token = 1* especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" ---------------------------------------------------------------------- Comment By: David Woodhouse (dwmw2) Date: 2006-11-29 11:53 Message: Logged In: YES user_id=81423 Originator: YES Hm, good point; thanks. I've fixed the script which generates mail for each commit to the Linux kernel git tree, and it should no longer generate encoded-words longer than 75 characters. I still see this input... Subject: =?UTF-8?Q?[MTD]_NAND:_CAF=C3=89_NAND_driver_cleanup,_fix_ECC_on_reading?= =?UTF-8?Q?_empty_flash?= and this output... Subject: =?UTF-8?Q?[MTD]_NAND:_CAF=C3=89_NAND_driver_cleanup, _fix_ECC_on_reading?= =?UTF-8?Q?_empty_flash?= The comma is allowed, and doesn't have to be '=2C', does it? See ?4.2 (3) and ?5 (1). ---------------------------------------------------------------------- Comment By: Harald Hoyer (Red Hat) (saturn_de) Date: 2006-11-29 10:44 Message: Logged In: YES user_id=5540 Originator: NO http://www.ietf.org/rfc/rfc2047.txt An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100103&aid=1605144&group_id=103