On 2002.02.23, in <[EMAIL PROTECTED]>,
"Jerry Van Brimmer" <[EMAIL PROTECTED]> wrote:
> < .
> pop_authenticate: Using any available method.
> > AUTH CRAM-MD5
> < + PDMyNzU3LjEwMjAyMjMxMjUzMzRAaXNwd2VzdGVtYWlsLmFjZXdlYi5uZXQ+
> mutt_sasl_cb_authname: getting authname for pop3.ispwest.com:110
> mutt_sasl_cb_pass: getting password for [EMAIL PROTECTED]@pop3.ispwest.com:110
> > amVycnl2YkBpc3B3ZXN0LmNvbSAxNGI0MjNiMmQ5ODQyNGNjYjY2OTNhZDM2MWM0MTBlMg==
> < +OK jerryvb's mailbox has 665 message(s) (2526032 octets)
> SASL authentication failed.
> > APOP [EMAIL PROTECTED] c6157f678c257df79923897ddf14ab04
> < -ERR unknown or invalid command in this state [APOP]
> APOP authentication failed.
> > USER [EMAIL PROTECTED]
> < -ERR unknown or invalid command in this state [USER]
> Login failed. USER: unknown or invalid command in this state [USER]
This seems like a disagreement between what happens and what mutt
expects to happen. You're authenticating using CRAM-MD5, and the POP
server is validating the authentication. Then mutt thinks that is
rejected it, so it tries other authentications, which the server does
reject, since it's not expecting an authentication anymore.
In other words, this looks like a mutt bug.
You might try setting $pop_authenticators to work around this. The goal
would be not to try authenticating with MD5 -- for example:
set pop_authenticators="apop:user"
--
-D. [EMAIL PROTECTED] NSIT University of Chicago
