pop3

[forsyth@plan9.cs.york.ac.uk forsyth@plan9.cs.york.ac.uk]

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).