* pop3
@ 1997-01-30 9:55 forsyth
0 siblings, 0 replies; 6+ messages in thread
From: forsyth @ 1997-01-30 9:55 UTC (permalink / raw)
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).
^ permalink raw reply [flat|nested] 6+ messages in thread
* pop3
@ 1997-01-30 9:13 Boyd
0 siblings, 0 replies; 6+ messages in thread
From: Boyd @ 1997-01-30 9:13 UTC (permalink / raw)
the client should be a popfs. the server could reply like ftp with:
USER boyd
+OK Encrypt challenge 123 for boyd.
^ permalink raw reply [flat|nested] 6+ messages in thread
* pop3
@ 1997-01-30 6:28 Lucio
0 siblings, 0 replies; 6+ messages in thread
From: Lucio @ 1997-01-30 6:28 UTC (permalink / raw)
> +OK Pop3 Server ready <123.45678@xxx.com>
>
MH has a worthy POP server (and client) in its very confounded and
confounding implementation. Perhaps not for the faint hearted, but
certainly worth a look.
It does provide APOP as well as some even cleverer extensions.
--
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.
^ permalink raw reply [flat|nested] 6+ messages in thread
* pop3
@ 1997-01-30 6:14 Brandon
0 siblings, 0 replies; 6+ messages in thread
From: Brandon @ 1997-01-30 6:14 UTC (permalink / raw)
On Wed, 29 Jan 1997, Russ Cox wrote:
> >of secure authentication. if the client side had a useful operating
> >system, you might interpose a `secure' connection between client and
> >server, to prevent the password being seen.
>
> for that matter, if the client side had a useful operating
> system, you could interpose a secure, authenticated connection
> and not require a password.
>
> p.s. is apop somehow encrypted or disguised? i've only seen it
> as an option in eudora.
>
Check out the rfc's I referred to (1731 and 1734 I _think_...)... They
said something about "apop"... it had something to do with the server
initially giving an identification message like:
+OK Pop3 Server ready <123.45678@xxx.com>
where xxx.com was the host, and 123 and 45678 were the pid of the server
and some other number..
Then the user did a (md4 maybe?) hash of a string consisting of that
server id string plus his/her password, and returned the hash to the
server to authenticate...
Or something like that...
brandon
................................. ..............
: Brandon Lee Black : [Office] :.............: [Personal] :....
:....................: brandon.black@wcom.com : photon@nol.net :.......
: "Sanity is the : +1.281.362.6466 .......: photon@gnu.ai.mit.edu :
: trademark of a :.................:..../\: vis_blb@unx1.shsu.edu :
: weak mind. . ." : LDDS WorldCom, Inc. :\/: +1.281.397.3490 ......:
:....................:.....................:..:.................:
^ permalink raw reply [flat|nested] 6+ messages in thread
* pop3
@ 1997-01-30 2:15 Russ
0 siblings, 0 replies; 6+ messages in thread
From: Russ @ 1997-01-30 2:15 UTC (permalink / raw)
>of secure authentication. if the client side had a useful operating
>system, you might interpose a `secure' connection between client and
>server, to prevent the password being seen.
for that matter, if the client side had a useful operating
system, you could interpose a secure, authenticated connection
and not require a password.
p.s. is apop somehow encrypted or disguised? i've only seen it
as an option in eudora.
^ permalink raw reply [flat|nested] 6+ messages in thread
* pop3
@ 1997-01-30 1:15 forsyth
0 siblings, 0 replies; 6+ messages in thread
From: forsyth @ 1997-01-30 1:15 UTC (permalink / raw)
as far as we can tell, none of the pop3 clients that people actually
use here, including most of the famous ones, support any useful form
of secure authentication. if the client side had a useful operating
system, you might interpose a `secure' connection between client and
server, to prevent the password being seen.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~1997-01-30 9:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-01-30 9:55 pop3 forsyth
-- strict thread matches above, loose matches on Subject: below --
1997-01-30 9:13 pop3 Boyd
1997-01-30 6:28 pop3 Lucio
1997-01-30 6:14 pop3 Brandon
1997-01-30 2:15 pop3 Russ
1997-01-30 1:15 pop3 forsyth
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).