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