Mailman 3 November 2006 - Mailman-coders

[ mailman-Patches-657951 ] Generate RSS summary in archives
by SourceForge.net 19 Aug '22

19 Aug '22

Patches item #657951, was opened at 2002-12-23 14:17 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i… Category: Pipermail Group: Mailman 2.2 / 3.0 Status: Open Resolution: None Priority: 7 Submitted By: A.M. Kuchling (akuchling) Assigned to: Nobody/Anonymous (nobody) Summary: Generate RSS summary in archives Initial Comment: Here's a first-draft patch. Things that need fixing: * The generated RSS feed needs to be validated. (It passed the W3C's RDF validator, but RSS validators still need to be checked.) * The date should be given in YYYY-MM-DD format, which requires parsing the .fromdate attribute. * How do I get the URL for an archived message? The generated RSS currently just uses the filename, which is wrong. How do I get at the PUBLIC_ARCHIVE_URL setting? * Getting the most recent N postings is inefficient; the code loops through all of the archived messages and takes the last N of them. We could add .last() and .prev() methods to the Database class, but that's more ambitious for 2.1beta than I like. (Would be nice to get this into 2.1final...) * The list index page should have a LINK element pointing to the RSS file. Please make any comments you have, and I'll rework the patch accordingly. ---------------------------------------------------------------------- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2003-04-18 18:43 Message: Logged In: YES user_id=12800 Andrew, to get the url for the archived message use mlist.GetBaseArchiveURL(), which knows about private vs. public archives, the host name and the list name. From there you should be able to tack on just the part of the path under "archives/private/listname". See Mailman/Handlers/Scrubber.py for an example. Only other minor comment: NUM_ARTICLES can probably go in Defaults.py.in ---------------------------------------------------------------------- Comment By: Justin Mason (jmason) Date: 2003-03-26 16:49 Message: Logged In: YES user_id=935 big thumbs up from me too. Much better solution than http://taint.org/mmrss/ ;) ---------------------------------------------------------------------- Comment By: Uche Ogbuji (uche) Date: 2003-03-17 20:09 Message: Logged In: YES user_id=38966 I'd like to add my vote to this item. This is a fantastic idea, Andrew. Thanks. --Uche ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 15:42 Message: Logged In: YES user_id=11375 Updated patch: * Dates are now rendered as ISO-8601 (date only, not the time of the message) * By hard-wiring 2002-December, I got the RSS to validate using Mark Pilgrim's validator. ---------------------------------------------------------------------- Comment By: captain larry (captainlarry) Date: 2002-12-23 14:36 Message: Logged In: YES user_id=147905 Just voting for support here. This is *great* thanks for the patch and I hope the maintainers include it as soon as it's appropriate :) Adam. ---------------------------------------------------------------------- Comment By: Barry A. Warsaw (bwarsaw) Date: 2002-12-23 14:27 Message: Logged In: YES user_id=12800 Deferring until post-2.1 ---------------------------------------------------------------------- Comment By: A.M. Kuchling (akuchling) Date: 2002-12-23 14:21 Message: Logged In: YES user_id=11375 Argh; SF choked on the file upload. Attaching the patch again... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=300103&aid=657951&group_i…

2 1

[ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers
by SourceForge.net 30 Nov '06

30 Nov '06

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_… 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(a)bar.org, baz(a)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*<Any CHAR except SPACE, CTLs, and especials> especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" encoded-text = 1*<Any printable ASCII character other than "?" or SPACE> ; (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*<Any CHAR except SPACE, CTLs, and especials> 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_…

1 0

[ mailman-Patches-1605292 ] patch to add sync_members functionality to the Web UI
by SourceForge.net 29 Nov '06

29 Nov '06

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_… 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_…

1 0

[ mailman-Feature Requests-1074197 ] Web interface to sync_members
by SourceForge.net 29 Nov '06

29 Nov '06

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_… 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_…

1 0

[ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers
by SourceForge.net 29 Nov '06

29 Nov '06

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_… 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(a)bar.org, baz(a)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*<Any CHAR except SPACE, CTLs, and especials> especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" encoded-text = 1*<Any printable ASCII character other than "?" or SPACE> ; (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*<Any CHAR except SPACE, CTLs, and especials> 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_…

1 0

[ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers
by SourceForge.net 29 Nov '06

29 Nov '06

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_… 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*<Any CHAR except SPACE, CTLs, and especials> especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" encoded-text = 1*<Any printable ASCII character other than "?" or SPACE> ; (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*<Any CHAR except SPACE, CTLs, and especials> 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_…

1 0

[ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers
by SourceForge.net 29 Nov '06

29 Nov '06

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_… 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*<Any CHAR except SPACE, CTLs, and especials> especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / " <"> / "/" / "[" / "]" / "?" / "." / "=" encoded-text = 1*<Any printable ASCII character other than "?" or SPACE> ; (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*<Any CHAR except SPACE, CTLs, and especials> 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_…

1 0

[ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers
by SourceForge.net 29 Nov '06

29 Nov '06

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_… 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*<Any CHAR except SPACE, CTLs, and especials> 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_…

1 0

[ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers
by SourceForge.net 29 Nov '06

29 Nov '06

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_… 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_…

1 0

[ mailman-Bugs-1605144 ] mailman corrupts RFC2047-encoded headers
by SourceForge.net 29 Nov '06

29 Nov '06

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_… 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_…

1 0