Re: how do disable SASL when compiling imap-2004a?
On Tue, 17 Aug 2004, ml wrote: I understand that USER/PASS is insecure. However, there are [broken] servers out there which advertise "USER" and "AUTH CRAM-MD5" but in fact support "USER" only! So, when my c-client enabled stuff doesn't work with such servers, users would complain since their e-mail clients (e.g. Outlook) would work. If all you want to do is disable a particular SASL authenticator when it is broken on the server, then just do e.g. mail_parameters (NIL,DISABLE_AUTHENTICATOR,"CRAM-MD5"); to disable CRAM-MD5. This will still permit the use of other SASL authenticators. c-client will never use USER/PASS unless there are no suitable SASL authenticators. You should never do this unilaterally; the user should be required to configure it. In particular, note that by default, modern versions of good POP3 servers disable the USER/PASS commands. So it is *NOT* a good idea to disable SASL and make a client use USER/PASS by default. In fact, it is a terrible idea. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: how do disable SASL when compiling imap-2004a?
On Mon, 16 Aug 2004, Mark Crispin wrote: >On Thu, 29 Jul 2004, ml wrote: >> Is there a way to disable all SASL based authentication when compiling >> imap-2004a? > >Sorry for the delay in answering. > >The general answer to your question is "no"; however, you can modify the >source code. > >Why do you want to disable SASL authention? USER/PASS is very insecure >and should not be used. Mark, Thanks for the response. I trust that you have had a good vacation. I understand that USER/PASS is insecure. However, there are [broken] servers out there which advertise "USER" and "AUTH CRAM-MD5" but in fact support "USER" only! So, when my c-client enabled stuff doesn't work with such servers, users would complain since their e-mail clients (e.g. Outlook) would work. Is there a way to force pop3.c to fall back to USER/PASS when CRAM-MD5 fails? For now, I have hacked pop3.c to make it use USER/PASS only. Thanks. Cheers, N.
Re: IMAP: PARSE - Invalid mailbox list: <>
On Fri, 13 Aug 2004, Shawn Walker wrote: What am I'm doing wrong with the email address? I have the following set: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> I don't see what could cause c-client to return an error. What is the actual string that you are passing? The parser is complaining about you passing: <> which is invalid except as a Return-Path. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: MBX Folders and file size after deletion
On Mon, 19 Jul 2004, Erik Kangas wrote: The case in point is with UW IMAP v2004 and MBX folders. Repeated deletions and expunges successfully remove large messages, but the physical folder remained [essentially] unchanged in size. This seems to happen sometimes, but not always. I see that nobody answered this while I was on vacation. Expunged messages can only be removed from the mailbox when an expunge or checkpoint happens while only one session has the mailbox open. Shared expunge just marks the message as invisible; exclusive access is needed to do the message removal (I call it "burping"). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: concurrent EXAMINE/SELECT on unix format mailbox
On Mon, 16 Aug 2004, Nick wrote: However, my concern is when using examine (read only) on a mailbox and another connection uses select. Examine appears to be completely oblivious to any actions performed on the mailbox by the other process. Specifically, an expunge really throws things out of whack where subsequent text fetches on the "examined" view returns incorrect data which seemingly correspond to the original view offsets when first opened rather than the current updated mailbox (post-expunge). Your surmise is correct. In traditional UNIX format, there is effectively only one lock: the readwrite lock. Readonly access must either lock the readwrite lock (which would preclude other readonly access), or not lock at all and hope for the best. c-client does the latter. This is one of many reasons why traditional UNIX format is not suitable for IMAP (or other shared access). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: UW-2004a and IPv6 & FreeBSD 4.10
On Mon, 2 Aug 2004, Peter Losher wrote: Restarted inetd, and all IPv6 queries bomb out w/ this error message: Aug 2 17:35:58 newbox imapd[44126]: Command stream end of file, while flushing line user=??? host=[NON-IPv4] Sorry for the delay in responding; I was on vacation. If you are getting "NON-IPv4" then the imapd binary you are running was built as IPv4 only (that is, IP=4 which is the default for UNIX builds). Did you do a "make clean" before setting IP=6? Note that this is not the underlying problem. "Command stream end of file" simply means that the client disconnected without doing a LOGOUT command. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: how do disable SASL when compiling imap-2004a?
On Thu, 29 Jul 2004, ml wrote: Is there a way to disable all SASL based authentication when compiling imap-2004a? Sorry for the delay in answering. The general answer to your question is "no"; however, you can modify the source code. Why do you want to disable SASL authention? USER/PASS is very insecure and should not be used. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
concurrent EXAMINE/SELECT on unix format mailbox
I originally ran across this on a vendor supplied build (redhat 7.2) and verified it again using Fedora Core 2 and imap-2004a. I apologize if this was previously covered; however, I am bringing it up since it doesn't appear to be explicitly mentioned in docs/formats.txt When using the unix format mailbox only one process can have read/write (select) access. This is documented, and any previous connections are dropped. However, my concern is when using examine (read only) on a mailbox and another connection uses select. Examine appears to be completely oblivious to any actions performed on the mailbox by the other process. Specifically, an expunge really throws things out of whack where subsequent text fetches on the "examined" view returns incorrect data which seemingly correspond to the original view offsets when first opened rather than the current updated mailbox (post-expunge). Thanks, -nick -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
