Re: bulk transfer with differing capabilities
Tomas Pospisek wrote: Have you had a look at mailsync? I see nothing in the documentation to suggest that it can deal with one server that supports folders with messages and subfolders and a second server which does not. In fact, the WHATSNEW file notes that as of release 5.0.0 it should be possible to sync stores which contain folders with messages _and_ submailfolders. However if two stores do not _both_ allow messages _and_ subfolders in folders at the same time, submailboxes will be created first and messages in folders that contain subfolders will no be synchronized! That reads as a pretty clear statement that mailsync cannot adapt my existing mail store to conform to the limited capabilities of the destination server. If I find a different tool that can automatically "homogenize" my folders on the source server first, perhaps then I'll use mailsync for the bulk transfer. So thanks, Tomas, for bringing it to my attention. But my search continues
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 --
compile error
I'm trying to compile IMAP and I keep getting the following error: imap-2004c1]# make slx . . . ln -s ip4_unix.c ip_unix.c ln: `ip_unix.c': File exists make[3]: *** [onceenv] Error 1 make[3]: Leaving directory `/usr/local/imap-2004c1/c-client' make[2]: *** [slx] Error 2 make[2]: Leaving directory `/usr/local/imap-2004c1/c-client' make[1]: *** [OSTYPE] Error 2 make[1]: Leaving directory `/usr/local/imap-2004c1' make: *** [slx] Error 2 I've found that other users compiling this had no problem on fedora (using the slx as machine type). I'm using fedora 3. I figured dovecot was maybe conflicting, but I removed the dovecot package and same error comes up. I try other OS types (lnx, lrh) and still nothing. Any ideas? Thanks, mike
Re: compile error
On Tue, 1 Feb 2005, Kowal, Michael wrote: ln: `ip_unix.c': File exists ip_unix.c is a file that is made as part of the build. It should not exist when the build is started. Try doing a "make clean" and then try the build again. If you got your copy from a third-party, try getting it directly from the UW distribution at: ftp://ftp.cac.washington.edu/mail/imap.tar.Z -- 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 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 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: compile error
Worked perfectly, but I get errors about SSL. Is there a way I can tell make where my installation of SSL is (e.g ssl is currently installed in /usr/local/ssl/)? Thanks, mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Crispin Sent: Tuesday, February 01, 2005 4:38 PM To: Kowal, Michael Cc: c-client@u.washington.edu Subject: Re: compile error On Tue, 1 Feb 2005, Kowal, Michael wrote: > ln: `ip_unix.c': File exists ip_unix.c is a file that is made as part of the build. It should not exist when the build is started. Try doing a "make clean" and then try the build again. If you got your copy from a third-party, try getting it directly from the UW distribution at: ftp://ftp.cac.washington.edu/mail/imap.tar.Z -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
RE: compile error
On Tue, 1 Feb 2005, Kowal, Michael wrote: Worked perfectly, but I get errors about SSL. Is there a way I can tell make where my installation of SSL is (e.g ssl is currently installed in /usr/local/ssl/)? /usr/local/ssl is the default location. If you are building on Linux, you should use "make lnp" or "make slx" rather than one of the vendor versions (e.g. "make lrh"). The only difference between the vendor versions and "make lnp" is that the vendor versions reflect their non-default locations for SSL. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
