headers
Unknown | 9 Jul 2002 17:56

Re: UTF-8 and RFC 2047

# John Stanley said:
# > Stop mailing me copies of this stuff. How many times do I need to say
# > that?

Oh good grief! People are just hitting the group reply and responding.
Give it a rest and focus on what is important. 

# Clive D.W. Feather said:
# Then set the Reply-To header. Or ask the list operator to fix it. 

It is not broken as has been discussed in the past.

# Or install a duplicate message detector like procmail.

Yes. Or better yet... just hit the delete key on the extra copy.

--

-- 
Kent Landfield                        Phone: 1-817-545-2502
Email: kent <at> landfield.com             http://www.landfield.com/
Search the Usenet FAQ Archive at http://www.faqs.org/faqs/
Search the RFC/FYI/STD/BCP Archive at http://www.faqs.org/rfcs/
Permalink | Reply | 0 comments |
headers
Unknown | 9 Jul 2002 18:58

Re: UTF-8 and RFC 2047

# >>>>> "Kent" == Kent Landfield <kent <at> landfield.com> writes:
# 
#  > # Clive D.W. Feather said:
#  > # Then set the Reply-To header. Or ask the list operator to fix it. 
# 
#  Kent> It is not broken as has been discussed in the past.
# 
# I'm sorry, but having the list actively inserting Reply-To with the
# same content as From _is_ broken.
# 
# -- 
# Andrew.

Point taken. That has been removed.

--

-- 
Kent Landfield                        Phone: 1-817-545-2502
Email: kent <at> landfield.com             http://www.landfield.com/
Search the Usenet FAQ Archive at http://www.faqs.org/faqs/
Search the RFC/FYI/STD/BCP Archive at http://www.faqs.org/rfcs/
Permalink | Reply | 0 comments |
headers
Unknown | 9 Jul 2002 19:12

Re: UTF-8 and RFC 2047

# > I'm sorry, but having the list actively inserting Reply-To with the
# > same content as From _is_ broken.
# 
# Yes! This has been driving me nuts for months on a half dozen lists I am
# on. I hit reply and enter, followed by cancel because the wrong address is
# in the reply-to, hit reply again, 'y' for reply to all recipients, do some
# surgery on the 'To' and 'Cc' lines to remove the incorrect 'reply-to' now
# in the 'To' line and to move the list address from a 'Cc' to the 'To'.
# 
# This is a damn well _broken_ setting for a list to use. It makes what
# should be a simple and routine reply to the list into an absurdly complex
# exercise.

Lets take this off line...  The situation is this... What you are talking 
about is having all messages generated with a 

   Reply-To: usenet-format <at> landfield.com 

I have been beat up over this before when I had it set to the list. People
didn't like every response, even private ones going to the list.

The majordomo setup here was changed to replyto = $SENDER a while back 
after such a discussion. I never heard another thing about it. I just 
removed the replyto setting so it does not insert a Reply-To at all.  
This will not correct what you are talking about.  It will also not correct 
what John was complaining about either. A group reply will still work as 
before generating a duplicate message to the author of the message being 
replied to.

--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ian Bell | 12 Jul 2002 13:49

Re: [Meta] List's Reply-To (was: UTF-8 and RFC 2047)

On Thu, 11 Jul 2002, J.B. Moreno <planb <at> newsreaders.com> wrote:
>On 7/11/02 6:03 AM, Charles Lindsey at <chl <at> clw.cs.man.ac.uk> wrote:

>> I have not yet seen a mail reader that is aware of whether or not a
>> message came from a mailing list. How does it tell?
>
>Configuration.  I'm using Outlook Express for the Mac

>As I said above, the mailing list manager allows me to customize how "Reply"
>is handled.

>This is basically how any modern mail client should handle the situation
>(and per a recent discussion in demon.ip.support.turnpike, I understand it's
>how Turnpike handles it,

it is...

>which makes Clive's use of "Reply group" rather
>puzzling).

        Date: Tue, 9 Jul 2002 15:47:50 +0100
        From: "Clive D.W. Feather" <clive <at> demon.net>
        User-Agent: Mutt/1.4i

Mutt may not have mailing list management in the same way as OE(mac) or
Turnpike :-(

--

-- 
Ian Bell                                           T U R N P I K E
(Continue reading)

Permalink | Reply | 0 comments |
headers
Clive D.W. Feather | 1 Jul 2002 10:40

Re: Yes, Rat's nest

Erland Sommarskog said:
>>   (BTW, in the last 2 years there are cases where bad unicode
>>   implementation was responsible for security problems in MicroSoft's IIS,
>>   so saying there are no normalization/encoding issues seems premature.)
> Were these issues related to normalization?

Or were they related to bad handling of UTF-8 "overlong" sequences ? This
is a known security hole, and is why all software handling UTF-8 *MUST*
detect overlong sequences.

--

-- 
Clive D.W. Feather  | Work:  <clive <at> demon.net>   | Tel:  +44 20 8371 1138
Internet Expert     | Home:  <clive <at> davros.org>  | Fax:  +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            | NOTE: fax number change
Permalink | Reply | 5 comments |
headers
Charles Lindsey | 1 Jul 2002 12:26
Picon
Picon

Re: UTF-8 quickfix for moderated groups

In <1fehg46.sd9kckjpfxgcM%dennis.scp <at> multiweb.nl> dennis.scp <at> multiweb.nl (Dennis SCP) writes:

>ASCII moderated groups would work as today.

>UTF-8 moderated groups asks of servers not to inject anything into
>tålk.serious but instead inject it into tålk.serious.unmoderated 

But what stops ordinary users (not just moderators) subscribing to
tålk.serious.unmoderated? Moreover, that group is going to be flooded all
over the world, just so that the moderator (at some random point in the
world) can be sure to see it.

Yes, it would work if we could absolutely find no other solution, but we
are not in that state yet.

--

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: chl <at> clw.cs.man.ac.uk      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
Permalink | Reply | 0 comments |
headers
Jean-Marc Desperrier | 1 Jul 2002 14:47

Re: Yes, Rat's nest

Clive D.W. Feather wrote:

>Or were they related to bad handling of UTF-8 "overlong" sequences ?
>
They were. Embedding of a "/" character inside an "overlong" sequence.
Permalink | Reply | 0 comments |
headers
Jean-Marc Desperrier | 1 Jul 2002 16:39

Re: Subject Line Data

Erland Sommarskog wrote:

>As for the ones in wi.*, tw.* and cn.*, whatever the charset is not
>UTF-8. (Well, I have no idea where wi.* comes from, but "##YMILK" where
>"Y" is Cyrillic is not likely to be anything, is it?)
>
The rest of the wi group is in chinese BIG-5, and when you set the 
character set to BIG5, this character is decoded as a valid chinese 
character.
Permalink | Reply | 0 comments |
headers
Charles Lindsey | 1 Jul 2002 13:10
Picon
Picon

Re: UTF-8 and RFC 2047

In <yl7kkgxxvf.fsf <at> windlord.stanford.edu> Russ Allbery <rra <at> stanford.edu> writes:

>Erland Sommarskog <sommar-usefor <at> algonet.se> writes:

>> This is something I like to be strengthened, but I don't know really
>> how.  SHOULD is definitely not right. "should as a matter of good
>> practice" maybe.

I am a bit dubious about using "should" in contexts where people might
read it as "SHOULD".

>Something like:

>   It is recommended, as a last recourse, that characters in unknown
>   character sets be passed unaltered and displayed in the default
>   character set so long as they are not control characters in that
>   character set.  This is better than altering or rejecting the
>   characters since the user will at least have some chance of making
>   sense of the text.

Likewise ising "recommended" where "RECOMMENDED" might be (mis)understood.
Better to keep such advice in a NOTE. I now have:

   Encoding by other means is not compliant with this standard.
   Nevertheless, encoding using other character sets (with no indication
   of which one beyond the user's ability to guess based upon other
   clues in the article, or custom within the newsgroup) has been in use
   in some hierarchies, and such usage may be expected to continue for
   some period after the introduction of this standard.  Reading agents
   MUST support the use of UTF-8, [RFC 2047] and [RFC 2231] in headers
(Continue reading)

Permalink | Reply | 5 comments |
headers
Charles Lindsey | 1 Jul 2002 12:47
Picon
Picon

Re: UTF-8 and RFC 2047

In <3D1CAD61.8040508 <at> certplus.com> Jean-Marc Desperrier <jean-marc.desperrier <at> certplus.com> writes:

>Charles Lindsey wrote:

>>But OTOH we don't want to give it even the respectability that a "SHOULD
>>NOT" might imply, so I carefully avoided that by say explicitly that it
>>"is not compliant with this standard". That way we give the right message,
>>whilst not opening ourselves to yet another accusation that "USEFOR is
>>riding roughshod over all existing practice...".
>>
>I can't agree with that.

But I don't see exactly what your disagreement is.

>The way to accomodate with existing with existing practice is given 
>below when explaining what to do when recognizing that headers are not 
>in UTF-8.

Yes, it says you MAY do that. Someone has asked for words such as "best
current practice" to be added.

>The standard must be clear that the continuing use of unencoded local 
>encoding is not conformant.

Yes. That is exactly what my text says.

>It may not make everybody happy, but the reason for that will be that 
>they want to change nothing, and if we go that way, we will stay with a 
>non-working situation forever.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane