From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 30 Jan 1997 09:55:20 +0000 From: forsyth@plan9.cs.york.ac.uk forsyth@plan9.cs.york.ac.uk Subject: pop3 Topicbox-Message-UUID: 54d31fb0-eac8-11e9-9e20-41e7f4b1d025 Message-ID: <19970130095520.cFxYpF-Cb2uwNGwO38UMBzpR1d-xsqpODaqeaw1E9tY@z> APOP uses MD5 encryption. the RFCs do indeed define a small selection of moderately secure authentication methods. the catch is that almost no existing client -- the ones our users actually want to use from PCs -- implements those methods. there was code to support APOP in the free implementation of Eudora, but when we asked the author about it (eg, how do we switch this on?), he said it wasn't really supported. microsoft exchange does not support it. netscape didn't support it (on PCs) the last time we checked. pegasus mail did not support it. and so on. a plan 9 client talking to a pop3 server might well implement a popfs as boyd suggests. (similarly for nntp, emphasising yet again how many of these wretched underpowered protocols go away given a general file service protocol, with authentication factored out at a higher level.) >>It does provide APOP as well as some even cleverer extensions. the Internet protocol extension racket is a complete pain: you often find that many things simply haven't written down by the vendor in (say) an auxiliary RFC. it's even more irritating when they've spent so much time implementing extensions they haven't bothered to implement correctly the part of the protocol that's actually written down in an RFC. >>for that matter, if the client side had a useful operating >>system, you could interpose a secure, authenticated connection >>and not require a password. sorry, i wasn't clear. what i was suggesting really only applied to existing clients on non-Plan9 systems that cannot easily be taught to use different techniques. if you can authenticate a connection, then get the pop3 client to use it, that's ideal (you still need a dummy user/password because the protocol requires it, but that's easy).