
fil@bok.net said:
However it's not only a question of 'Réf.' but of any accentuated Subject: when it comes to the digest issue. So mailman is also a little faulty here.
Not really. You cannot have 8 bit characters in header lines - the character set etc applies to the body, so that subject is broken to start with.
[from previous message]
Usually it get morphed from Réf. : confirmation of subscription - request 170967 into something like =?iso-8859-1?Q?R=E9f._:_confirmation_of_subscription_--_request_170967?=
so some MTA is converting the broken subject into some form of MIMEish encapsulation - basically coping with a broken message by applying a semi-broken workaround.
So I guess mailman should, before doing anything, convert these back to ascii.
not sure you want mailman to start doing conversions around other people's breakage. One possibility might be to make the subject line have more of a key in it hopefully picked to not have char set implications - say that kast part be [[CONFIRM#170967]] and just look for that style tag ignoring everything else in the line - making sure that the tags chosen don't get hit by those 8 bit conversion problems.
Nigel.
-- [ - Opinions expressed are personal and may not be shared by VData - ] [ Nigel Metheringham Nigel.Metheringham@VData.co.uk ] [ Phone: +44 1423 850000 Fax +44 1423 858866 ]

However it's not only a question of 'Réf.' but of any accentuated Subject: when it comes to the digest issue. So mailman is also a little faulty here.
Not really. You cannot have 8 bit characters in header lines - the character set etc applies to the body, so that subject is broken to start with.
This is perfectly legal. RFC 2047 supercedes RFC 822 and defines character encoding within headers, including the Subject: header.
[from previous message]
Usually it get morphed from Réf. : confirmation of subscription - request 170967 into something like =?iso-8859-1?Q?R=E9f._:_confirmation_of_subscription_--_request_170967?=
so some MTA is converting the broken subject into some form of MIMEish encapsulation - basically coping with a broken message by applying a semi-broken workaround.
Regarding the use of Ref: vs. Re:, there's nothing in RFC 822 that requires it to be one way or another. Subject: is defined as a *text type, which expands to "any CHAR, including bare CR & bare LF, but NOT including CRLF".
not sure you want mailman to start doing conversions around other people's breakage. One possibility might be to make the subject line have more of a key in it hopefully picked to not have char set implications - say that kast part be [[CONFIRM#170967]] and just look for that style tag ignoring everything else in the line - making sure that the tags chosen don't get hit by those 8 bit conversion problems.
I agree that this is a better solution.
Chris
participants (2)
-
Christopher P. Lindsey
-
Nigel Metheringham