On 185, 07 03, 2004 at 01:01:15AM +0300, Timo Sirainen wrote:
On Fri, 2004-07-02 at 10:27, Andrey Panin wrote:
AUTHNTICATE APOP will not work in IMAP session anyway because it doesn't pass initial responce required for APOP, so looks like this check is not really necessary.
Currently it doesn't, but there most likely will be extension which adds initial response support for IMAP. I think there already was a draft.
POP3 RFC also says:
It is conjectured that use of the APOP command provides origin identification and replay protection for a POP3 session. Accordingly, a POP3 server which implements both the PASS and APOP commands should not allow both methods of access for a given user; that is, for a given mailbox name, either the USER/PASS command sequence or the APOP command is allowed, but not both.
Yeah, I read this RFC part and IMHO it's quite stupid. IIRC here is no such restriction for AUTH command, why APOP should be different ?
I thought the same.. And I don't see a "MUST" there, so maybe it's not that important.
Anyway, I committed the patch with several other changes to implement dovecot-auth-trusted challenge.
There's still one problem. It's possible that connecting to dovecot-auth takes longer than accepting a POP3 client. In that case get_apop_challenge() fails because it doesn't know about auth connections yet. So, the greeting string should really be delayed until all auth connections are done. I left it there as FIXME, but moving it into clients_notify_auth_connected() probably would fix it..
I didn't actually test any of my changes, so it might be broken as well..
Hmm, it's really broken:
Jul 5 12:39:22 pazke dovecot: pop3-login: APOP auth connection lost [80.254.111.17]
On the client side I see that connection is closed immediately after APOP command. I'll try to trace it down some time later.
-- Andrey Panin | Linux and UNIX system administrator pazke@donpac.ru | PGP key: wwwkeys.pgp.net