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.

The built-in function `md5' will encode a given string if it is a
multibyte string.  The coding-system for encoding is decided by
the following way:

(symbol-value (car coding-category-list))

You can find those procedures in fns.c.

Mule-UCS will put the coding category `coding-category-utf-16-le'
in the forefront of `coding-category-list' by default.  The
default value of `coding-category-utf-16-le' is `utf-16-le'.  And
a string extracted from a multibyte buffer will be a multibyte
string even if it does not contain non-ascii characters.  Thus
the code

(md5 (concat pop3-timestamp pass))

and

(md5 (encode-coding-string (concat pop3-timestamp pass) 'utf-16-le))

are equivalent and a string will be altered to 16-bit characters
as follows:

(encode-coding-string "dingnusdingnus" 'utf-16-le)
 => "\377\376d^@i^@n^@g^@n^@u^@s^@d^@i^@n^@g^@n^@u^@s^@"

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.


2002-03-15  Katsumi Yamaoka  <yamaoka@jpl.org>

	* pop3.el (pop3-string-as-unibyte): New macro.
	(pop3-apop): Use it.