Hi Tim, sorry for the late reply. I was on a vacation without net access.
On Wed, 26. Dec 2007, 19:57:36 +0000, Tim Small wrote: > Tim Small wrote: > > or if I just leave the auth string blank.... The server does appear to > > support plain authentication tho' - if I telnet into it, I can issue > > USER and PASS commands manually..... > > OK, so it seems I had plain and user authentication methods mixed > up.... Unfortunately, the ISP of the charity that I'm configuring these > boxes for only supports USER and APOP auth, and not over SSL/TLS > either! It would be cool if the docs could say that the "apop" and > "user" auth methods are the lowest common denominator... > > Maybe it would be useful if there was an "allow_insecure_auth=yes" type > configuration parameter, which tried to use secure auth methods, but > then fell back to insecure ones in a least-bad-first manner? That would be nice for servers that don't support secure authentication methods. It is not implemented because I'm hoping that there are only very few such servers active, so that there's not much need for it. For a long time, USER was the only insecure method, so if mpop could not use a secure method, you had to configure "auth user", and that was it. But recently man-in-the-middle attacks were documented for APOP so that mpop considers it insecure since version 1.0.9. It is however still much better than USER authentication, and with the additional sanity checks added in 1.0.9, it is highly unlikely that a successful attack is possible against mpop using APOP. So now one has the choice between two insecure methods, and APOP is the preferred one. Still I'm not sure if it's worth to add another configuration option for what I hope to be a corner case. > If this was not chosen, then the docs could indicate this... Should I > submit a documentation patch? It is documented that mpop will not choose an insecure method automatically, and that USER and APOP are considered insecure, but admittedly that part of the documentation is confusing. If you have an idea how to improve it, a patch would be most welcome. Martin ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ mpop-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mpop-users
