From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/43894 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: pop3.el broken Date: Fri, 15 Mar 2002 19:03:04 +0100 (CET) Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: main.gmane.org 1016215555 18570 127.0.0.1 (15 Mar 2002 18:05:55 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Fri, 15 Mar 2002 18:05:55 +0000 (UTC) Cc: ding@gnus.org, Original-Received: from hermes.netfonds.no ([195.204.10.138]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 16lw5O-0004pQ-00 for ; Fri, 15 Mar 2002 19:05:55 +0100 Original-Received: from malifon.math.uh.edu (malifon.math.uh.edu [129.7.128.13]) by hermes.netfonds.no (8.10.1/8.9.3) with ESMTP id g2FI59M29416 for ; Fri, 15 Mar 2002 19:05:09 +0100 (CET) Original-Received: from sina.hpc.uh.edu ([129.7.128.10] ident=lists) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 16lw36-0004IP-00; Fri, 15 Mar 2002 12:03:28 -0600 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Fri, 15 Mar 2002 12:03:34 -0600 (CST) Original-Received: from sclp3.sclp.com (qmailr@sclp3.sclp.com [209.196.61.66]) by sina.hpc.uh.edu (8.9.3/8.9.3) with SMTP id MAA23793 for ; Fri, 15 Mar 2002 12:03:21 -0600 (CST) Original-Received: (qmail 409 invoked by alias); 15 Mar 2002 18:03:08 -0000 Original-Received: (qmail 402 invoked from network); 15 Mar 2002 18:03:07 -0000 Original-Received: from 178.230.13.217.in-addr.dgcsystems.net (HELO yxa.extundo.com) (217.13.230.178) by gnus.org with SMTP; 15 Mar 2002 18:03:07 -0000 Original-Received: from yxa.extundo.com (localhost.localdomain [127.0.0.1]) by yxa.extundo.com (8.12.2/8.12.2) with ESMTP id g2FI34KY017418; Fri, 15 Mar 2002 19:03:05 +0100 Original-Received: from localhost (jas@localhost) by yxa.extundo.com (8.12.2/8.12.1/Submit) with ESMTP id g2FI34QO017415; Fri, 15 Mar 2002 19:03:04 +0100 X-Authentication-Warning: yxa.extundo.com: jas owned process doing -bs Original-To: Katsumi Yamaoka In-Reply-To: Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:43894 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:43894 On Fri, 15 Mar 2002, Katsumi Yamaoka wrote: > The problem that the return value of `md5' for a multibyte string > and a unibyte string differ under Emacs 21 is caused by Mule-UCS. > However, it is not a bug of Mule-UCS. What we should do is to > improve pop3.el after all. I will attach a new patch. This patch looks OK. Out of curiosity, is it sufficient to, instead, pass 'binary as CODING-SYSTEM to `md5'? It seems as if the problem really is `md5' guessing incorrectly about a good coding system to use, using hints provided by Mule-UCS. Converting the string into unibyte before calling md5, as your patch does, is one solution, but maybe the string can be passed directly to `md5' if you provide it with a better coding system to encode the string as. > Even if Mule-UCS is not used, a string as the first argument of > `md5' is always encoded by some coding-system, but almost all > coding-systems will not alter an ascii text. Exceptionally, it > is a very rare case but it is possible that if a person has set > the value of `coding-category-iso-7' with the coding-system > `iso-2022-jp-1978-irv' (which is known as "old JIS") and push > `coding-category-iso-7' into `coding-category-list', she or he > would not be able to use the apop authentication with pop3.el. > In my opinion that it should never be her or his fault. The problem really is that POP3/APOP does not define in what encoding the password should be encoded into before inputting it to the hash function. It is left as a customization things, which means that only ASCII will interoperate unless you configure your client to what the server uses. The best would be if the protocol said "the password should be encoded into UTF-8" before hashed. Hm. Perhaps pop3.el should always encode the password as UTF-8 instead of using string-as-unibyte. At least it seems more configurable, if you make the 'utf-8 choice customizable. But I haven't tried it, so maybe passing 'utf-8 to `md5' does not work. (I remember that I really did not understand what I was doing when I wrote `md5'.)