Re[2]: POP servers not advertising USER in CAPA reply
On Tue, 1 Feb 2005, Mark Crispin wrote: >On Tue, 1 Feb 2005, Vadim Zeitlin wrote: >> In theory I totally agree but in practice there is this broken server >> which doesn't support any other way to login except by using USER but still >> doesn't advertise it. It's clearly is a bug in server implementation and >> using USER is the only way to work around it. > >The server may not be broken. > >They may have an administrative policy that clients should use the SSL >POP3 service (port 995) instead of unencrypted POP3 port 110; but for the >benefit of old pre-SSL clients (which also would not use CAPA) it allows >the USER/PASS commands. I have come across at least two pop servers that don't advertise USER and yet don't use SSL-POP3 nor any other authentication schemes. Both of them are at rather large ISPs (here in Japan.) As the chance of getting their sys. adm. to change their behavior is less than zero, I had to patch my c-client-based stuff. Nonetheless, the c-client distrubtion should NOT be changed in order to serve mis-configured servers. It is the responsibility of c-client users, like myself to make the relevant changes. And yes, the banner offered by my patched ipopd clearly shows that it has been patched:) -- N. -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Re[2]: POP servers not advertising USER in CAPA reply
On Tue, 1 Feb 2005, Vadim Zeitlin wrote: In theory I totally agree but in practice there is this broken server which doesn't support any other way to login except by using USER but still doesn't advertise it. It's clearly is a bug in server implementation and using USER is the only way to work around it. The server may not be broken. They may have an administrative policy that clients should use the SSL POP3 service (port 995) instead of unencrypted POP3 port 110; but for the benefit of old pre-SSL clients (which also would not use CAPA) it allows the USER/PASS commands. The alternative is to not be able to login at all which may be correct (although in fact I don't see anything specifically forbidding use of USER in RFC 2449, it only states that its presence in CAPA response means that USER/PASS are supported but doesn't say anything about its absence!) but is absolutely useless. Not at all. Did you try the SSL POP3 service? Speaking practically, what problems can I have if I still use USER even if the server doesn't advertise it? Doing so violates the specifications, and may very well violate the intentions of the POP3 server administrator. Worse, you may find yourself accused of "behaving just like Microsoft" in violating specifications for convenience. All too often the excuse of "a necessary workaround" has been offered as to why Outlook, etc. violates a specification. Still worse, if it's considered to be something that c-client does, *I* will be accused of "behaving just like Microsoft." No thanks. :-) AFAICS in the worst case the server will reply that command is not supported. This doesn't seem very bad to me. No. If it doesn't reject until the PASS command then the result is that passwords are sent in the clear. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re[2]: POP servers not advertising USER in CAPA reply
On Mon, 31 Jan 2005 18:04:04 -0800 (Pacific Standard Time) Mark Crispin <[EMAIL PROTECTED]> wrote: MC> c-client's POP3 client code is behaving correctly. Sorry for being unclear: I have absolutely no doubt about this. However the correct behaviour is not very useful in this case. MC> A POP3 server that does not advertise USER in CAPA is specifically stating MC> that USER is forbidden; it is the exact equivalent of an IMAP server that MC> advertises LOGINDISABLED. A POP3 client MUST NOT send a USER command to a MC> POP3 server that supports CAPA but does not advertise USER. In theory I totally agree but in practice there is this broken server which doesn't support any other way to login except by using USER but still doesn't advertise it. It's clearly is a bug in server implementation and using USER is the only way to work around it. The alternative is to not be able to login at all which may be correct (although in fact I don't see anything specifically forbidding use of USER in RFC 2449, it only states that its presence in CAPA response means that USER/PASS are supported but doesn't say anything about its absence!) but is absolutely useless. Speaking practically, what problems can I have if I still use USER even if the server doesn't advertise it? AFAICS in the worst case the server will reply that command is not supported. This doesn't seem very bad to me. Thanks, VZ -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
