Re: possible imaprc.txt erratum
On Tue, 19 Apr 2005, Mark Brand wrote: But still, even with this understanding, what happens if there is no INBOX at all? That's where magic begins. You'll have to read the code in the dummy driver to understand. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: set new-folder-format same-as-inbox broken?
On Mon, 18 Apr 2005, Mark Brand wrote: Could it be that set new-folder-format same-as-inbox documented in http://www.washington.edu/imap/documentation/imaprc.txt.html does not work in imap-2004c1? I have done a bunch of tests with this and it seems to have no effect when the INBOX is in mbx format. It works for me. I just tried it. Note that an mbx-format INBOX must exist in order for this to work. set disable-plaintext nil nil is not a valid argument. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: possible imaprc.txt erratum
The text is correct. If INBOX is an empty file, it defaults to the system standard (which is traditional UNIX format on most systems, but MMDF on SCO). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: What does CLIENT BUG in result of STATUS operation mean?
On Sat, 16 Apr 2005, Mike Schmidt wrote: Can someone tell me what the CLIENT BUG references mean in the status report? It means that you did a STATUS command on the selected (opened) mailbox; a completely unnecessary and wasteful operation which could also have additional severe negative consequences. When you have a mailbox selected, the IMAP state already has all the data that a STATUS command could return. The STATUS command is to the be used only to get this data from a mailbox which is *NOT* selected. This has been shown to be an area which many novices fail to understand; many seem to believe (incorrectly) that you have to do a STATUS to get updated mailbox state. Learning how IMAP really works in this case is likely to help client authors understand IMAP in other cases, hence this is a mistake that I felt is important to correct. This is a transcript of the IMAP status operation. The client is based on c-client, running in Windows XP, and the server is uw-imapd running over a TLS connection (on Linux) If the client was written using c-client, then you did a mail_status() call on a mailbox name when you already had a perfectly good MAILSTREAM with all the data you need from a mail_open() call. The correct procedure is to get the data from the MAILSTREAM. For example, in your case of getting: (MESSAGES RECENT UNSEEN UIDNEXT UIDVALIDITY) you should use stream-nmsgs stream-recent either do a mail_search() for unseen and count the number of responses coming back, or if all message metadata is in c-client's cache just count the number of messages which have !mail_elt(stream,i)-seen, for i=1 to nmsgs. stream-uid_last+1 stream-uid_validity The simplest way to get the RECENT count is: mail_fetch_fast (stream,1:*,NIL); for (i = 1, j = 0; i = stream-nmsgs; ++i) if (!mail_elt (stream,i)-seen) ++j; However that mail_fetch_fast() should only be done once in any session. If you've already gotten all the message metadata once you don't need to get it again. IMAP automatically updates it for you. A STATUS command forces the IMAP server to do its open mail_open() call get the data from the resulting MAILSTREAM, then close it. But it already has done a mail_open() on that mailbox, as has your client. Hence the waste. The multiple opens can also cause other problems. Thanks very much. This certainly looks pretty confusing to me, but I' m just getting started writing a client using c-client. The message is obnoxious for a reason; it's to get the client author's attention and get him to ask what's going on? (and hopefully the explanation will convince him to do the right thing instead of abusing STATUS). So, in this case, it worked as designed. If there's anything unclear about any of the above, please ask. I'm not sure if the above answer adequately explains why as opposed to what. Also, please don't feel bad; you have lots of company in having made this mistake. You responded intelligently as well (ask and find out what's wrong); too many people just try to hide the message and never fix what their client is doing wrong... :-( -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: What does CLIENT BUG in result of STATUS operation mean?
On Sat, 16 Apr 2005, Mike Schmidt wrote: Now I have an additional quick question, more a design question than anything else: if I understand correctly, I should have 1 mailstream open to an imap server, not one per mailbox. I should reuse this mailstream when switching mailboxes instead of making a new one, is that correct? What happens to the message cache in this case? It's a bit more complicated than that. You should have one MAILSTREAM open for each mailbox which you want to be open *simultaneously*. If you want to switch from one open mailbox to another, it is better to reuse the mailstream than to close the existing mailstream and open a new mailstream on the new name. With any of these operations, there are certain costs: Opening a new connection has the cost of TCP/IP session initiation, encryption negotiation, and authentication negotiation. Selecting a mailbox has the cost of server overhead to load/process the mailbox, and the protocol overload of loading the client cache. Closing a mailstream has the cost of discarding the message cache for the old name and closing the TCP/IP session. Opening a new mailstream has both the opening a new connection and the selecting a mailbox cost. Recycling a mailstream has the cost of discarding the message cache for the old name and selecting a mailbox, but avoids the costs of closing the TCP/IP session and opening a new connection. Keeping multiple sessions open allows you to monitor multiple mailboxes simultaneously, but there is a practical limit of how many mailboxes that you should have open at a time, no more than a handful. You want to do this if you want immediate real-time access to the mailbox and its messages, as opposed to passive monitoring. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: symbolic links to mailboxes and locking
On Thu, 14 Apr 2005, Mark Brand wrote: Is it safe for several users to be accessing the same mbx mailbox via different symbolic links pointing to that mailbox? Yes. However, don't use NFS with mbx format. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: caching and mailbox synchronisation with c-client
As a first order approximation: You should have on record the UIDVALIDITY of the mailbox, highest assigned UID in the mailbox ever seen by the client, and UIDs of all messages. If the IMAP server reports a different UIDVALIDITY then what you have, dump your entire cache; it has been invalidated so you have to reload everything. Otherwise, if the UIDVALIDITY is the same, then identify new messages by doing tag UID FETCH n+1:* FAST (instead of FAST, you may want ALL or FULL or whatever else you would like to know about new messages at synchronization time). For n+1, substitute the highest assigned UID plus 1. For example, if the highest assigned UID is 4392, then do something like: tag UID FETCH 4393:* FULL and load your cache with the returned data. If you only get back one message, then that message is the highest-numbered UID message in the mailbox (not necessarily the highest UID ever assigned, since subsequent messages could have been deleted and expunged). Next, compare the number of messages you have cached with the number of messages reported by EXISTS in the response to SELECT. If this is different, the EXISTS value is probably smaller than what you have, meaning that many messages had been deleted and expunged (if EXISTS is larger, then you have a bug in your application since you failed to cache some old message). An easy way to determine what messages were deleted is to fetch the UID map of the old messages with tag UID FETCH 1:n UID (where n is the highest assigned UID as above). A slightly less chatty way to do this is tag UID SEARCH UID 1:n ALL. The UIDs that aren't returned are the ones that you need to remove from your cache. This is a pretty simpleminded mechanism. It's possible to do a lot better, particularly by observing that sequence numbers have no holes and that UIDs are strictly ascending; these are very useful properties. But learn to walk before you run is a good point here; start with something simple like this, and then try to make it fancier. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: imapd changing ctime
On Mon, 11 Apr 2005, Rob Henderson wrote: We have observed that the UW imapd is changing the ctime on mail folders on every access, even when the folder is not modified. Fair question, unfair answer. :-) Blame the designers of UNIX. There is no way to peek at the contents of a file without changing either the atime or the ctime. If atime is changed, then checks for new mail based on atime will get false negatives. If after a peek you restore the atime to its previous value, the ctime gets changed as a side effect. One of the design goals of the new mailbox format we have under development is to address the backup problem. Since the underlying problem occurs with having mailbox metadata in the same file with message data, the only way to solve the problem is to split mailbox metadata into a different file. So, help is on the way, but there's no short-term solution. If you break imapd's changing of ctime, then you'll break new mail checking. You could try to convince the UNIX geeks of the world that their notion of file dates is wrong-headed, and that it should be possible for an application to peek at a file without altering its metadata in any way. Point out that, because of this UNIX design bug, backup applications (such as dump) kludge around this by doing raw filesystem access. However, I don't have much hope that you'll convince anyone, other than old farts like me who remember TOPS-20 and other systems which did file dates properly... :-( -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Problem with MBX INBOX
On Fri, 8 Apr 2005, Clive McDowell wrote: I have a strange problem with an MBX format INBOX. It contains 6618 messages but only the most recent 33 are being displayed by PINE or any other clients I've tried. That means that the other 6585 messages were deleted and expunged in a shared session. Those messages will be removed (and the space they occupy reclaimed) the next time an expunge or checkpoint is done in an exclusive session. The power tool ftp://ftp.cac.washington.edu/mail/powertool/unexpunge.c can be used to turn off the expunge bits for those messages. Feed the file to its stdin, and get the unexpunged version on stdout. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: imapd for MacOS X - Authentication errors
On Thu, 7 Apr 2005, Matthew Leingang wrote:
Now when I try to connect using an IMAP client (even telnet localhost 143)
I can't login. I get the NO LOGIN failed response.
Does this happen when you make an SSL (port 993) connection to your IMAP
server?
Does Entourage do a STARTTLS command? If it doesn't, then you must use
port 993 and not port 143.
I've also tried
building with the arguments SSLTYPE=unix (to allow plaintext logging in,
kind of a no-no). Same problem.
Did you make sure that when the server started, that LOGINDISABLED does
*not* appear in the CAPABILITY list (you'll see it in the server greeting
banner)? If LOGINDISABLED appears, then you are running a SSLTYPE=nopwd
build server.
Note that you must do a complete rebuild (make clean) if you want to
change the SSLTYPE option. There are wizardry ways to avoid this, but
don't distract yourself with that for now.
Please keep me informed of your progress. Unfortunately, greater security
means that there are more things to go wrong, but we'll get you going and
happily IMAPing.
Related question: Once it gets working, I only want to allow connections on
the IMAP port from localhost. Can I do that with the
/etc/hosts.{deny,allow} files?
Yes.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Re: rfc 3348 (CHILDREN extension) support?
On Thu, 7 Apr 2005, Matt Selsky wrote: Are there any plans to add RFC 3348 support to imapd? CHILDREN is being replaced by LISTEXT in the IETF IMAP Extensions Working Group. Among other desirable things, LISTEXT will require the client to indicate that it wants children information. The bad thing about CHILDREN is that a server that does it must always do it. With a UNIX filesystem, that means that you must open the directory and examine its contents, which means a lot more work in the case of % wildcards. You seem to be asking not about CHILDREN, but rather about suppressing listing of directories which you don't have access to. If you do that, you get into issues about why you can't create a mailbox with the name of a list-suppressed mailbox, or what about lower-level names that you can access. For example, suppose you can access /foo/bar/zap but not the superior /foo/bar -- do you really want to suppress bar from being listed in /foo? The point is, yes, you can do as you propose, but that isn't what CHILDREN is about, and you may create other problems for yourself (and your users). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: rfc 3348 (CHILDREN extension) support?
On Thu, 7 Apr 2005, Matt Selsky wrote: Am I correct in that we'd want to modify dummy_list_work() to implement this? To alter list behavior, yes. Either there or in dummy_listed(), which has filters for other reasons. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: mh_header performance patch
Thank you very much! The next release will be imap-2004d, a maintenance release. imap-2004d is under a coding freeze for the upcoming Pine 4.63 release, and so your changes won't make it in in imap-2004d. However, I'm doing some related performance improvements, as part of the imap-2005 work, to other drivers. Your changes, or a variants of these changes, will definitely be part of imap-2005. Thanks again! -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: followup on email about nested directories..
In order to create mailboxes within a mailbox, you need to use a mailbox format which supports this dual-use. mbx format is not such a format; nor is traditional UNIX mailbox format. The dual-use mailbox formats supported in the distribution version of c-client are mh, mx, and news. Personally, I think that dual-use is a bad idea from a user interface point of view, since that means that for a name you have to have a separate open as mailbox and open as directory operation. But this seems to be a matter of religion. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
RE: Solaris imap-2004c1 can't find mailbox
On Thu, 10 Mar 2005, Bruce Shaw wrote: I'm not using INBOX. I'm using /var/mail/whatever-the-user-name-is. Ah. I understand now. When you give a specific filename, then a file by that name must exist. However, there is no reason why you should need to do this; to refererence your own mailbox, you should always use the name INBOX. Use of the name INBOX prevents this problem. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
RE: Solaris imap-2004c1 can't find mailbox
On Thu, 10 Mar 2005, Bruce Shaw wrote: OK, now I'm confused. Back awhile ago I was using a variant of cyrus-IMAP that required a specific file named INBOX to be sitting in your home directory. Yes, you're confused, and I think that it's a good idea to resolve the confusion, because otherwise you may have substantial problems in the future. Cyrus IMAP uses its own file structure (no home directories), so I don't think that you were using Cyrus (or if you were you've misunderstood what was going on). I'm not using INBOX. I'm using /var/mail/whatever-the-user-name-is. When you give a specific filename, then a file by that name must exist. I'm relying upon sendmail to handle mail file creation. It has a mind of its own. That's unimportant. See below. However, there is no reason why you should need to do this; to refererence your own mailbox, you should always use the name INBOX. Sendmail does not support that AFAIK. This is unimportant. INBOX is not a sendmail concept; it is an IMAP concept. The IMAP server accepts the name INBOX from the IMAP client, and the IMAP server knows how to translate the concept of INBOX into whatever your mailer (e.g. sendmail uses). More importantly, IMAP knows that INBOX always exists (even if there is currently no corresponding file on the filesystem -- it treats that situation as an empty INBOX). There is no need to reference the /var/mail/username file by that name from an IMAP client. Use INBOX in the IMAP client, and let the IMAP server do the magic that it does so well. The whole point of INBOX is that the IMAP client does not ever need to know what sort of mailer you have; you may have sendmail, Exchange, or Bombastic Blurdybloop's Best Bit Basher. As far as the IMAP client is concerned, it's all INBOX. Use of the name INBOX prevents this problem. Hence we were creating the /var/mail/whatever file and populating it with a dummy record. I suspect the nature of that dummy record may have changed from version 2000 to 2004. In effect, you didn't understand the magic that was going on, and you used magic to try to get the right result. Unbeknownst to you, it was black magic. There is one of those fortunate cases where you can solve the problem by doing less instead of more. Don't create files with those dummy records (just let the software do it), and don't try to use the /var/mail names; just use INBOX and let all the good magic work for you. :-) Good luck. Please keep me informed on how it goes. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
RE: Solaris imap-2004c1 can't find mailbox
On Tue, 8 Mar 2005, Bruce Shaw wrote: I reinstalled everything the way I figured it should be set up and left it overnight intending to fight with it in the morning. During the night a message came in and was successfully processed. /var/mail/username now appears to contain a valid DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA record. I guess IMAP just needed an incoming email message. This is strange. The software is supposed to work even if the mailbox is empty or doesn't exist. What was the problem that you were experiencing? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Solaris imap-2004c1 can't find mailbox
Just as a friendly reminder, the imap@u.washington.edu mailing list is for discussions of the IMAP protocol. Software questions about UW imapd should go to [EMAIL PROTECTED] We're going to do something about these mailing list names. Even though the actual software is called c-client, most people don't remember that name... You don't need to build with SSLTYPE=none if you want to allow your Java client to connect with plaintext passwords. SSLTYPE=unix will also work, that is: make gso SSLTYPE=unix This will build with SSL but without disabling plaintext passwords. It should work given what you've described. What, exactly, happens when it tries to find the mailbox it can't? Do you get an error message? If so, what is the message? Do you get a seemingly empty INBOX? What are the *exact* contents of the first line of a /var/mail/username file that exhibits this problem? On Mon, 7 Mar 2005, Bruce Shaw wrote: Solaris 2.8. Mailer is sendmail. Mail shows up in /var/mail/username I'm compiling using gcc. make gso SSLTYPE=none because I need a java client to be able to connect with plaintext passwords. Yes I know it's bad. We'll fix the app later. When I use mtest everything works fine. I get prompted for a password but when it tries to find the mailbox it can't. I've tried it with and without mbox, with and without a dummy first record (copied from another system). Another time I did this, pine helped me create the mailbox but this time it appears to have made matters worse. I've tried hardcoding the mail directory. Anybody got this working under Solaris 8? -- This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal and or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed. -- - For information about this mailing list, and its archives, see: http://www.washington.edu/imap/imap-list.html - -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: c-client support for client certificates?
On Thu, 24 Feb 2005, Kevin P. Fleming wrote: If I implement this, would it be more consistent to make it a callback route that returns a pointer to an allocated chunk of memory (with the caller responsible for freeing), or a parameter where I actually pass in the PEM-encoded string and c-client duplicates it into its own memory? c-client will only need the certificate for a very short time (to make two calls into the SSL library during the context setup), so I don't think it makes sense to keep a copy of it in c-client's memory space... Probably a callback set via mail_parameters() makes more sense for the reasons you state. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: c-client support for client certificates?
No, c-client does not have any support for SSL client certificates. The [GS]ET_SSLCERTIFICATEQUERY mail_parameter() callback routine is used to allow the application a chance to decide whether to proceed or abort if the *server* certificate fails validation. On Thu, 24 Feb 2005, Kevin P. Fleming wrote: Is there any way currently to get c-client to accept a client certificate (PEM-encoded string representation) and pass it along when OpenSSL asks for it during the TLS negotiation? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: What to do with VERY large mailbox files?
On Tue, 15 Feb 2005, Nicolas Kowalski wrote: Are there any news about this alternative format ? Not yet. I've been bogged down in other tasks. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: syslog: IMAP toolkit crash: Lock when already locked
On Tue, 15 Feb 2005, Jose A. Fabregas Reyes wrote: I have a Tru64 V5.1A DS20 machine. One o twice at day, i get this message: syslog: IMAP toolkit crash: Lock when already locked Just as a friendly reminder, the imap@u.washington.edu mailing list is for matters pertaining to the IMAP *protocol*, not for software issues. The correct mailing list for questions about the UW IMAP toolkit is [EMAIL PROTECTED] Please use the latter address in the future. Thank you. The Lock when already locked error message indicates a software bug which is supposedly impossible in UW imapd. It has nothing to do with file locking; instead, it indicates a forbidden recursive call into the c-client library from a c-client callback in the application. What version of UW imapd are you running? Did your copy come directly from UW, or was it modified by a third party? Are you certain that the syslog came from UW imapd? Usually, the syslog will indicate the name of the program which output the message. It could be a bug in some other program which uses the c-client library. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Setting deleted flag before delivery
The short answer is: there is no option to deliver a message as deleted. As you discovered, your hack with X-Status won't work, especially not with messages in formats other than traditional UNIX (since X-Status is only with traditional UNIX format). To do it right, you'll have to add a switch to dmail to set \Deleted, that works much like the existing -s switch that sets \Seen. However, I question why you want to do this. What's the point of delivering a message if it's going to be deleted? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re[3]: POP servers not advertising USER in CAPA reply
On Wed, 2 Feb 2005, Vadim Zeitlin wrote: 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. Ok, but if they [still] allow it, there mustn't be much harm in using it. There is a substantial amount of harm if the purpose of allowing USER when not advertised is to provide temporary reclama for old clients. By doing the old client behavior, you could stymie the site's migration plans. Doing so is the type of behavior that Microsoft is often accused of doing: taking the expedient approach instead of the correct one. I find it sadly ironic that the open source community would even think of doing this, after all the years of Microsoft-bashing over this very issue. Speaking practically, what problems can I have if I still use USER the server doesn't advertise it? Doing so violates the specifications, and may very well violate the intentions of the POP3 server administrator. Again, not in this case. It most certainly does violate the specification. The minute your software is installed at a site which has such reclama, it also violates the intentions of the server administrator and adds to his (or her) headaches. Your software has no way of knowing that this is the case. I understand your point of view but you should realize, of course, that I am going to patch my c-client version (once again) because I can't tell the user with a straight face that I am not going to fix it when it's a whole of one line fix. In that case, honesty and morality requires that you also disclose to your user that your client is BROKEN and NON-COMPLIANT with the specifications, and that as a result it has a SECURITY BUG that will continue even when your user upgrades his server. The entire reason why USER is part of CAPA is to enable the behavior of client code (such as in c-client that you advocate disabling. You are breaking an important and valuable security mechanism that many people spent a long time developing. And for what reason? So your client works with one particular broken server! I still can't prevent myself from thinking that all this is a big waste of effort Then don't do it! There is no law that says that you have to support broken servers. The world does not become a better place by adding security bugs in order to accomodate broken software. If a site doesn't want to fix its server to comply with specifications and run your client, then your client isn't important to that site -- and that site shouldn't be important to you either. There are many other sites which run compliant servers; quite enough to keep you in business. -- 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: 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: 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.
Re: How do I send custom IMAP commands with c-client ?
On Fri, 28 Jan 2005, Patrick Bennett wrote: When using /authuser with Exchange I get the error 'Can't do /authuser with this server.' As you surmised, Exchange does not support it. I then set up a local test CommuniGate Pro server to try it. Your test shows that Communigate Pro doesn't support it either; or at least you attempted to use an id that did not have administrative privileges. These are server issues. If it isn't supported in the server, there is no way that a client can offer the facility. At least, unlike PROXYAUTH, you can ask the server vendors to support it and point to an RFC which describes it. -- 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 I send custom IMAP commands with c-client ?
On Thu, 27 Jan 2005, Patrick Bennett wrote:
One final comment. The whole idea of PROXYAUTH has been obsolete for a
decade, having been replaced with SASL authentication/authorization ID.
How do I generically support this feature with any given server a customer
might be using?
When you open the mailbox, use the /authuser= option, e.g.
{imap.example.com/user=fred/authuser=joe}inbox
where fred is the account to be logged into and joe is the
administrator account.
This is documented in naming.txt.
However, I have to say it's not particularly clear how to do it, since my two
tests to use it (using mtest) against Exchange and Communigate Pro failed.
Did you use /authuser=, or did you try to use the * hack?
There's also almost zero documentation about it. The only mention I saw was
in RELNOTES and it said to use an * in the userid to seperate the identity
Don't try to use the * hack. It's only supported by the UW IMAP
server, and only for ancient clients that can't do SASL.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
University of Washington IMAP toolkit version 2004c is now available
This note is to announce the availability of the University of Washington IMAP toolkit version 200c. This is a maintenance release with minimal user-visable changes, but some important bug fixes. Information about changes can be found in the release notes in file imap-2004c/docs/RELNOTES in the distribution. Source code for the latest IMAP toolkit release is available at: ftp://ftp.cac.washington.edu/imap/imap.tar.Z (MD5: d38ac05f2e886f8ccedcd2b5892b1df0) As with all IMAP toolkit releases, it is important that you carefully test and determine for yourself that it performs suitably in your environment before placing this new version into production use. The Pine Development Team -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Re: [PATCH] buffer overrun in rfc822_8bit()
Thank you. I agree with your suggested patch, and it will be in the next release. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: IMAP over SSL using port 993?
On Tue, 11 Jan 2005, Andrew Biggs wrote:
Specifically, I am finding that although Exchange
doesn't appear to support the STARTTLS capability (if
you know how to turn this on please let me know!), it
does apparently listen to port 993 for connections
that begin with a TLS negotiation, followed by IMAP.
SSL negotiation, not TLS negotiation. Specifically, the SSLv23 method, as
opposed to the TLSv1 method.
I suspect this is considered pretty non-standard, and
out of scope for c-client. Nonetheless, its a problem
I need to solve.
It's standard, but an older standard; and it is supported by c-client.
I was hoping for suggestions on how I might go about
making this work.
The work is already done for you.
Just add /ssl after the host name in the mailbox specification, e.g.
{imap.example.com/ssl}INBOX
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Re: unable to lock append mailbox
On Mon, 10 Jan 2005, Stefan Schulte wrote: Sometimes (and I don't see any dependencies) the tmail program writes the error message unable to lock append mailbox. The most likely cause is that either the /tmp directory is protected other than 1777, or that the lock file protection was changed from the (correct) 0666 to something else. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Crash in mail_setflag_full
On Wed, 5 Jan 2005 [EMAIL PROTECTED] wrote: I finally fixed it. The variable containing stream was overwritten by an overflow bug Was this in your code or in c-client? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Crash in mail_setflag_full
On Wed, 29 Dec 2004 [EMAIL PROTECTED] wrote: When I call the function this way mail_setflag_full(stream, valid_uid, \\Deleted, ST_UID) the program crash. Am i doing something wrong? Unfortunately, your report is too vague to diagnose without additional information. What type of crash do you get? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
ANNOUNING: University of Washington IMAP toolkit version 2004b
This message is to announce the release of version 2004b of the University of Washington IMAP toolkit, imap-2004b. This release is available on: ftp://ftp.cac.washington.edu/mail/imap-2004b.tar.Z The convenience link: ftp://ftp.cac.washington.edu/mail/imap.tar.Z now points to this version. This is a maintenance release, consisting primarily of bugfixes and reliability improvements; however there are now new ports for Solaris with Blastwave Community Open Source Software (gcs) and Mandrake Linux (lmd). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Re: copy folders/subfolders
On Tue, 28 Dec 2004, Andrew wrote: This is the first year I have used imap. All without incident. I have users that have created a folder trees based on the year. Do any of the utlities have a wild card capability to copy all the folders and subfolders in one command or do I have to copy the folder/subfolders one folder at a time. mailutil can copy a folder hierarchy. There's a man page associated with mailutil which gives more details. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Configuration problems
On Tue, 21 Dec 2004, Erich Beyrent wrote: I am running FreeBSD 5.3 and have built the latest version of imap. My problem is that I cannot seem to get IMAP to download any messages to my Outlook client. POP3 is working correctly - in my $HOME directory, I have a .mail file containing all the messages that sendmail dumps in there. What other configuration steps do I need to perform? First, you need to understand that the IMAP server does not download message *to* your Outlook client -- the Outlook client downloads messages *from* the IMAP server. There is no configuration necessary in the IMAP server for a standard system configuration. Normally, any configuration is done on the client; and indeed your problem may be entire a client configuration issue. Then again, it may not be. You say that sendmail dumps [messages] into a $HOME/.mail directory. This is not a standard location for mail to be delivered. If you have made a non-standard location for mail, it should not be surprising that you need to change software that accesses mail to look for the message in the non-standard location. In general, I recommend that only experts do such things, and that everybody else stay with the standard defaults. I also don't understand how sendmail dumps messages into a $HOME/.mail directory has anything to do with POP3 working correctly. So, in order to diagnose your problem further, you need to be a bit more specific about what is going on. If you have made non-standard changes to the location of mail, etc. then the first piece of advice that I will give you is to undo those changes and use the standard locations. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Support for UIDPLUS extension?
It would not be very difficult to implement UIDPLUS in the IMAP client code, especially just UID EXPUNGE. However, it is quite difficult to implement UIDPLUS in c-client in general -- in particular, for non-IMAP mail stores. UIDPLUS may happen in the future, but I can't predict when just now. On Fri, 17 Dec 2004, Andrew Biggs wrote: I have a message server that supports the UIDPLUS extension, and I'd like to be able to invoke the UID EXPUNGE command using c-client. I didn't see anything in the API doc which looked like it would do this. Is this an extension I should develop myself, or did I just not look hard enough? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: syntax for mail_open and mail_list?
On Mon, 13 Dec 2004, Andrew Biggs wrote:
Just using NIL for ref and * in the pat parameter
doesn't seem to be working out.
Leaving aside the small matter that * is an extraordinarily bad idea to
send to an IMAP server, you have to use an IMAP mailbox wildcard.
mail_list (imapstream,NIL,{imapserver.example.com}*);
* is a local mailbox wildcard.
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Re: mailutil transfer and bad messages
On Thu, 9 Dec 2004, Cliff Green wrote: Just a note - that's okay for an mbox-format folder, mbx folders are a different story; you'll probably need to copy those messages to an mbox folder, remove the extra header, then move them back to the mbx folder. What's OK for an mbox format mailbox is also OK for mbx; the problem is that it is not OK for Cyrus. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: mailutil transfer and bad messages
On Thu, 9 Dec 2004, Nicolas Kowalski wrote: Mark, which above conditions are accepted or rejected by UW-IMAP ? UW imapd does not reject any of these; it will accept whatever garbage you throw at it. Whether it does anything useful with that garbage subsequently depends upon the nature of that garbage. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: IMAP ANNOTATE MORE support
On Thu, 9 Dec 2004 [EMAIL PROTECTED] wrote: But I need ANNOTATE support. I've found on the website the you were planning to do the support, but I cant found anything in hte documentation. There is currently no support for ANNOTATE and ANNOTATEMORE in c-client. You are the first person who has asked for it. Please note that ANNOTATE and ANNOTATEMORE are still under development in the IETF IMAPEXT working group, and as such the specification is subject to change. I can not predict at the present time when ANNOTATE and/or ANNOTATEMORE support will be added. This is a fairly large capability, and there are other projects. It is possible that a basic IMAP-client only support (as opposed to general c-client support and UW imapd support) can be added soon rather than later. This would be on the lines of the existing support for ACL and QUOTA; meaning that you call internal IMAP driver functions through unofficial interfaces. If this is OK, please let me know. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: mailutil transfer and bad messages
On Wed, 8 Dec 2004, Nicolas Kowalski wrote: When I use mailutil transfer to copy a whole mailbox hierarchy from a uw-imap server to a cyrus one, it sometimes fails with the error message contains invalid header, and then stops. Is there a way to make mailutil ignore these badly formatted messages and continue the transfer ? That problem (the check for invalid header) is not in mailutil; it's in the Cyrus server. The Cyrus server is refusing to accept the message in question. Mailutil, in turn, stops when it ceases to be able to do what it was told to do. Mailutil has no way of knowing that the problem is just that silly check, or some more serious matter. I doubt very much that you would want to have mailutil tell you that a copy was done, only to find that most messages were not copied due to a serious problem. I suggest that you ask the maintainers of the Cyrus server if there is a way to disable that check. Otherwise, there is no way that you can truly copy your messages. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: smtp-issues
On Tue, 7 Dec 2004, Jochen Garcke wrote: void smtp_debug (SMTPSTREAM *stream); void smtp_nodebug (SMTPSTREAM *stream); which are mentioned in the docs and are prototyped in smtp.h are not declared in smtp.c or anywhere else as far as I can see. (using imap-2004a) You are correct; this was never implemented as it was decided not to do debugging this way. Can I somehow disable the CRAM-MD5 authentication for a SMTP-Stream using c-client (like pine does) ? It's the DISABLE_AUTHENTICATOR function of mail_parameters(), e.g. mail_parameters (NIL,DISABLE_AUTHENTICATOR,(void *) CRAM-MD5); Note that this is a global setting. You should only use this as a workaround, and instead convince the manager of the SMTP server to fix their server. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: How to manage custom flags for IMAP messages
On Thu, 2 Dec 2004, Shawn Walker wrote: How do I manage custom flags for IMAP messages. I want to be able to set \Forwarded, \ReplyToAll, etc on a message and be able to see them using c-client. You can not use \Forwarded or \ReplyToAll. You can, however, use Forwarded and ReplyToAll. These are keyword flags, and work just like other flags. All flags which start with \ are reserved to the IMAP protocol for definition and are not available for user definition. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: message/rfc822 attachments include headers in both header and body?
On Thu, 2 Dec 2004, Charles Dorner wrote: When it is recieved, c-client returns the headers in calls to both mail_fetch_header and mail_fetch_body when given the section number for the embedded message. Is this supposed to happen or is there a problem in the message that I need to reformat part of it? Do they return the same data? Or does mail_fetch_header() return just the header and mail_fetch_body() returns the entire message? Remember that these are not null-terminated strings; they are size-count strings. I suspect that the answers to the above questions are no and yes respectively. You should check that, just to be sure. If that is the case, can you then guess how to get the text of the message and the first body part? If you're still stumped, let me know and I'll carry you through the next step. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: message/rfc822 attachments include headers in both header and body?
On Thu, 2 Dec 2004, Charles Dorner wrote: Strange, I thought section numbers worked differently. So then, assuming that an e-mail has a single embedded message, I would want section 2 for mail_fetch_header and section 2.1 for mail_fetch_body? If an email consists solely of a single embedded message, it would be section 1 instead of section 2. Presumably, if you are using section 2, you have an email with a primary text content and an embedded message as an attachment, e.g. MULTIPART/MIXED TEXT/PLAIN primary text content MESSAGE/RFC822 embedded message In that case, then the following is true: mail_fetch_body() returns the entire body part section 1 = primary text content section 2 = entire embedded message section 2.1 = first MIME part of embedded message section 2.2 = second MIME part of embedded message etc. mail_fetch_header() returns the header of messages only null section= top level header section 2 = header of embedded message mail_fetch_text() returns the text of messages only null section= top level text section 2 = embedded message text Note that you can not call mail_fetch_header() or mail_fetch() text on section 1, nor can you call it on sections 2.1 or 2.2 unless those are also MESSAGE/RFC822 parts. Is it starting to make sense yet? The learning curve for how section numbers work *is* steep. The good news is that, when you finally understand the theory of section numbers, it'll be light a light bulb turning on in your head and then you can't imagine how it could be any other way. I thrashed through all of this when I developed it, and went through several different theories before I finally ended up with this one. If you are familiar with IMAP (RFC 3501), c-client section numbers are similar to IMAP section numbers, only in c-client they are always numeric. mail_fetch_body() = section mail_fetch_header() = [section.]HEADER mail_fetch_text() = [section.]TEXT mail_fetch_mime() = section.MIME In other words, mail_fetch_header() of section 2 is IMAP section 2.HEADER and mail_fetch_text() of section 2 is IMAP section 2.TEXT ... -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: reopening a stream with OP_HALFOPEN
On Wed, 1 Dec 2004, Tomas Pospisek's Mailing Lists wrote: I've got reports [1] against Debian's version of c-client 2002e that when opening a stream, that is not OP_HALFOPEN (such as OP_READONLY or NIL), c-client will actually close and open the stream again (thus requiring the user to re-authenticate). I assume that you're talking about recycling an already-open stream? A close and open will happen if c-client determines that the new mailbox name is not compatible with the existing stream. If you recycle a non-halfopen stream, and decide that you want the stream to be halfopen now, a close/open is required unless the server supports the UNSELECT capability. That's the only reliable way to get a halfopen session if the server does not have UNSELECT. If you don't care if the stream is halfopen or not, then you probably should not call mail_open() with the OP_HALFOPEN flag to recycle the stream. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: reopening a stream with OP_HALFOPEN
On Wed, 1 Dec 2004, Tomas Pospisek's Mailing Lists wrote: I'm looking at messages in readonly mode in order to determine which ones need to be synchronized between two sites. Then I'm flagging those as deleted that have been removed on one side. After that I'm appending new messages to mailboxes at both sides. In order to do this without having the Status: O set by c-client I need to change down into OP_HALFOPEN mode. Thanks for explaining so clearly what you're doing. I understand the issue. If the mailbox is opened readonly then there shouldn't be any Status: O set. c-client doesn't do this; the IMAP server does. If one of the IMAP servers is UW imapd, then indeed Status: O will happen when messages are appended to a mailbox that is open readwrite, since the readwrite session will see the messages. But that won't happen if it's open readonly. So, if Status: O is being written then I think that must be something that is happening in some other server. Or perhaps you don't really have the mailbox open readonly (perhaps because you don't always see new mail in readonly sessions). Anyway, the correct long-term fix is to upgrade to servers that support UNSELECT. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote.
Re: reopening a stream with OP_HALFOPEN
On Wed, 1 Dec 2004, Tomas Pospisek's Mailing Lists wrote: ... but - are you saying that I don't even need to change into HALFOPEN mode in order to be able to append messages to any kind of mailbox without the Status: O flag being set? That I just have to keep the stream in READONLY mode? Stream readonly status refers to operations on the opened mailbox (the selected mailbox in IMAP terms); it affects such operations as setting/clearing flags and expunging. It does not in any way affect operations that work on a mailbox by name, such as append. So I think that the answer to your question (if I understand it correctly) is yes. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: reopening a stream with OP_HALFOPEN
On Wed, 1 Dec 2004, Tomas Pospisek's Mailing Lists wrote: [1] http://www.mail-archive.com/c-client@u.washington.edu/msg00220.html That message did not consider the case of the stream being opened readonly. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: MBX mailboxes over iSCSI
On Tue, 23 Nov 2004, Yiorgos Adamopoulos wrote: Does anybody have any experiense on such a configuration? iSCSI partitions look like local disks to the OS (or at least this is my understandig) but in truth they reside on another server on the network. I doubt very much that mbx format will work on any network filesystem, even if the locking problem is solved. The only network filesystem that I know of in which mbx would work was the old TOPS-20 from two decades ago, and only because that filesystem had rigorous token passing on a page to guarantee that updates were atomic across all users of the network filesystem. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: IMAP NAMESPACE - How to get them?
On Mon, 22 Nov 2004, Shawn Walker wrote: How do I go about getting the IMAP NAMESPACE from c-client? I see GET_NAMESPACE, but I would like to get the list of NAMESPACE that the IMAP server return. If the stream argument to mail_parameters() is non-NIL, then GET_NAMESPACE will return the namespace from the stream's driver. This is only meaningful in the case of an IMAP stream. The NIL argument to mail_parameters() returns the local c-client namespace as you have observed. Cool, eh? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: unable to login in fedora
On Thu, 18 Nov 2004, Andrew wrote: I have been using imap-2004 without any problems. I recently upgraded to fedora FC2 and I can connect to the imap server, but keep getting a login failure. I looked in the makefile and there was not an entry for fedora. The lrh build is suitable for Fedora. What error message do you get. a login failure is not specific enough. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: imap access via ipo3d (fwd)
SSL_CERT_DIRECTORY is the directory for the *server* to find the local host public certificate, and SSL_KEY_DIRECTORY is the directory for the *server* to find the local host private key. These are *not* the directories for the CA certificates. The CA certificate directory is declared as part of the OpenSSL build. Apparently, you built OpenSSL with a different CA certificate directory than you actually used. If you think about it, you really want to use the CA certificate directory that OpenSSL was built with. Otherwise, each and every program that uses OpenSSL would have to be told where the CA certificates are located as part of their build; nor could you change the CA certificate directory without rebuilding all programs that use OpenSSL. It makes sense for programs to have configurability of their own certificates (such as the imapd and ipop3d server public certificates and private keys), but not the CA certificates. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: errors with pop3
On Mon, 8 Nov 2004, Timo Veith wrote: Because I don't have a recent version of uw-imap (not even modern) and I would prefer to leave uw-imap as it is, do you think it is a good idea to use exim for filtering out the X-UID header? If you can do this, yes that is an excellent idea. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Mailbox format how-to
On Mon, 8 Nov 2004, Chris Ross wrote: - modify sendmail.cf (and friends: submit.cf?) to call tmail instead of mail.local. The tmail man page has a little info on this. - Modify by calls in my procmailrc to use dmail instead of just specifying the mailbox name (i thing. this right?) So far, so good. So, is there any way to tell tmail to deliver to an mbx format main mail spool if the file doesn't already exist? I know if it exists, it'll deliver in the correct format, but what if it vanishes? The easiest way to do this is to edit file imap-200?/src/osdep/unix/Makefile to set CREATEPROTO=mbxproto instead of the current unixproto. Then rebuild the entire UW IMAP toolkit. However, once created, an mbx-format mailbox shouldn't vanish. So, it should work just to create empty mbx-format mailboxes for everybody who doesn't have it. It works to create one, and then copy it to each user (there isn't any user-specific in an empty mbx-format mailbox). That way, you don't have to do any rebuilding. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Mailbox format how-to
On Mon, 8 Nov 2004, Erik Kangas wrote: #!/bin/bash if [ ! -e $HOME/$1 ] [ $1 != .inbox ]; then /usr/local/bin/mbxcreat #driver.mbx:$1 fi /usr/local/bin/dmail +$1 I recommend using mailutil create instead of mbxcreat since the latter program is no longer supported. We didn't find any easier way to accomplish this for arbitrary folders; it would be nice if dmail could do this itself. I'm not sure that I understand. dmail never creates a non-INBOX mailbox; if the destination mailbox does not exist then dmail will deliver to INBOX. Do you mean convert mailbox format? If so, mailutil can be used to convert, albeit to a different name. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: mailbox format
On Sun, 7 Nov 2004, Akmal Khodjanov wrote: I was wondering if there is any c-client driver to treat mail messages as separate files. I would like to fetch mail messages from a mail server and save them in separate files each. The closest would be either mx or mh format. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Creating ENVELOPE and BODY from a string
Your call looks right, although the host argument should not be an empty string; if you don't want to specify a localhost pass a NIL argument to default to the internal BADHOST. When you say the body contents are empty what do you mean? At the very least you should have a TEXT/PLAIN body passed back. Also, why are you calling rfc822_parse_msg()? This is a very low-level routine in c-client. For most purposes, you would use the higher level mail_fetch_structure() instead. If you use the low-level routines, you may be causing yourself a lot more work than is necessary. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re[2]: Creating ENVELOPE and BODY from a string
On Wed, 3 Nov 2004, Akmal Khodjanov wrote: after rfc822_parse_msg when I try to ouput the envelope and body contents I get this: What do you mean by body contents? If you are talking about body-contents.text, that is not something that is set by rfc822_parse_msg(). In fact, that is not something that you should *ever* access in your application; it is strictly internal to c-client. That's why I suggest that you use the higher-level routines. If the message is truly in a non-mailbox form, you are better off writing a driver for it than calling rfc822_parse_msg() directly. Perhaps you can start by hacking the phile driver using the message loading capability from the mh driver. The proper use of rfc822_parse_msg() is very complicated, and only a careful study of mail.c will show you this. Fortunately, mail.c will do the work for you, if you have a driver. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re[2]: Creating ENVELOPE and BODY from a string
On Tue, 2 Nov 2004, Mark Crispin wrote: If you are talking about body-contents.text, that is not something that is set by rfc822_parse_msg(). In fact, that is not something that you should *ever* access in your application; it is strictly internal to c-client. If you really insist upon using rfc822_parse_msg(), you use body-contents.offset which is the offset into the stringstruct that you passed as the argument to rfc822_parse_msg(), along with the body-size.octets. body-contents.text is currently only used by the IMAP driver and by the sending modules (SMTP and NNTP send). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: questions about how to do multiple IMAP sessions to the server in c-client
On Mon, 1 Nov 2004 [EMAIL PROTECTED] wrote: 2. check the validity of the UIDs, (is there a function in c-client does this?) It's not a function. It's the uid_validity on the stream (e.g. stream-uid_validity). If it is different from the uid_validity from a previous stream, then none of the UIDs from the previous stream are useful any more. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: questions about how to do multiple IMAP sessions to the server in c-client
I strongly suggest that you buy a copy of the book Internet Email Protocols: A Developer's Guide, by Kevin Johnson, published by Addison Wesley, ISBN 0-201-43288-9. Your questions indicate a very basic misunderstanding of the IMAP protocol. Until that misunderstanding is clarified, you are going to have a very long and frustrating experience. On Thu, 28 Oct 2004 [EMAIL PROTECTED] wrote: What I really want is to make sure that after log-ed in until logout, it is counted as in one connection. It's one connection from the point that the initial TCP interchange is made (even before authenticated). If this is true, then after login until logout there can only be one mailbox being selected (one session there). There can only be one mailbox selected at a time. If you select mailbox2 while mailbox1 is selected, then mailbox1 is automatically unselected and mailbox2 is now selected. This forms a new session within the same connection. can have multiple MAILSTREAMs open, each with a separate mailbox selected, I believe you mean the mail boxes for the MAILSTREAMs might be SELECT'ed before and not closed, but only one is SELECT'ed at the moment. No. I mean that you can have multiple connections, each with a different mailbox SELECTed. This is the only way that you can have more than one mailbox SELECTed at a time. Also if the MAILSTREAM s1's mail box had been SELECT'ed before but now another mail box is SELECT'ed. Could we still call this MAILSTREAM s1 open until it is closed? Any existing MAILSTREAM is not affected by opening a new MAILSTREAM. Each MAILSTREAM is completely independent of any other MAILSTREAMs. By passing a non-null MAILSTREAM to mail_open(), you can do a new SELECT on a MAILSTREAM, without closing the connection. Will the data downloaded into cache while it was open be still in the c-client cache, until s1 is closed even if other mail box is SELECT'ed now (i.e. can still use some of the mail_xxx() function against this stream s1, such as get msg number..)? Each MAILSTREAM has its own cache. The cache is destroyed when the MAILSTREAM is closed, or if the MAILSTREAM is passed to mail_open() to SELECT a new mailbox. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Fwd: How to run the mtest?
Does this problem happen in the latest imap-2004b development snapshot on ftp://ftp.cac.washington.edu/mail/imap-2004b.DEV.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: adding a namespace for spam
On Wed, 20 Oct 2004, Ralf Utermann wrote: we currently test a mail system doing spam detection before delivery. Spam, which has been detected, as well as training mailboxes for good and spam, should be located in a separate directory (per user) on the server, not in the users home directory (because the spam training program has no access to the Homes). Could this be implemented with a separate namespace? Any hints about how to do this? I don't think that there's much point in having a separate namespace as opposed to just creating a mailbox (or a directory of mailboxes) named spam or junk to deposit the spam. Some clients handle namespaces poorly, so a simple mailbox or directory is probably a better place for the spam... -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: sending an embedded message with c-client (as an attachment in a TYPEMULTIPART e-mail)
On Sun, 17 Oct 2004, Charles Dorner wrote: I'm trying to format an envelope and body for sending through the smtp_mail() function. The message is type TYPEMULTIPART and has an attachment of type TYPEMESSAGE with subtype of RFC822. Set the TYPEMESSAGE text as if it was type TYPETEXT. Typically, you use TYPEMESSAGE when you are forwarding a message, which means that you already have it as a text string. It's therefore pointless to deconstruct the message just to have c-client reconstruct it; especially since the usual point of forwarding as MIME is to forward the message as-is. Look at the source code for Pine to see an example. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Freeing resources and internals.txt
On Thu, 14 Oct 2004, Frans Meijer wrote: It is not entirely clear to me if resources allocated and returned by library functions such as mail_fetch_structure should be freed using the mail_free* functions, or that the c-client libs take care of those (attached to mail_close perhaps)? No, you do not (MUST NOT) free any resource returned by any mail_?() functions. These resources are cached on the stream and are freed when the stream closes. You are, however, required to free resources that you created via: fs_get() cpystr(), cpytxt(), textcpy(), textcpystring(), textcpyoffstring() rfc822_base64(), rfc822_binary(), rfc822_qprint(), rfc822_8bit() utf8_text(), utf8_cstext(), utf8_cstocstext(), utf8_mime2text() Note that in the case of the utf8_() functions, you must check to see if the returned value is the same as the source, since these will not create a new copy if no conversions need to be done and instead will just return the argument. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Moving mail to ~user/mbox first goes to /var/mail/user?
On Wed, 13 Oct 2004, Todd Piket wrote: It's during this operation that we see the introduction of a significant number of null characters into the message, sometimes over 5MB (yes megabytes). The nulls always occur right before the From line of a message though they aren't always introduced. Hmm. I wonder if this is NFS inode vs. data cache skew; that is, the inode data returned by stat() (and in particular the file size) doesn't match the data on the NFS client. I forgot to mention in my last mention that this is imap-2002d. Is this possibly fixed in 2004a? Try it and see. Since this is probably not a c-client bug, and is instead something in your NFS infrastructure that c-client, it isn't clear that a version upgrade of c-client imapd will fix it. However, it could be that some subtle difference in how the new version does I/O may avoid tickling the NFS issue. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Moving mail to ~user/mbox first goes to /var/mail/user?
On Tue, 12 Oct 2004, Todd Piket wrote: 2.) This move operation does not dot lock the /var/mail/user file as a normal snarf does. What is doing this moving? It's not c-client, since c-client always dotlocks. Any ideas or workarounds? We are looking at Courier and maildir Courier is not an IMAP-compliant server. If you must go to maildir, look at Dovecot instead. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Help Running UW-IMAPD Under Cygwin
On Thu, 7 Oct 2004, overbored wrote: Let's say I sort all my mail from a mailing list to one folder, and all my mail from friends to another. If I get a message from my friend sent to both me and the folder, I would like for it to show up in both folders. Instead of using separate mailboxes (there is no such thing as folder in IMAP), perhaps you may want to use IMAP keywords? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: locking problem in imap-2002b
On Wed, 6 Oct 2004, Peter Ip wrote: These are unix format inboxes. (We are slowly migrating to MBX format.) Is there a situation where a temporary INBOX is created e.g. for expunge and if two imapds are running at the same time that one imapd gets the inode of another's temp file? Nothing like that happens in UW imapd, so whatever is going on is something else. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: ipop3/imap4 login problem
What operating system are you using? You seem to have obtained a modified distribution, because there is no such build option as -D WITH_SSL_AND_PLAINTEXT in the UW distribution. Have you tried the original UW distribution, on 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: message/delivery-status handling
On Thu, 30 Sep 2004, Ryan Dingman wrote: c-client (imap-2004a) seems to completely ignore the information contained in body parts whose content-type is message/delivery-status. Am I missing something? If not, are there any plans to add support for getting the information for this content-type? As in IMAP, all MESSAGE subtypes other than MESSAGE/RFC822 are treated as a basic type; that is, like APPLICATION, AUDIO, IMAGE, and VIDEO. The contents of that body part can be fetched as in the other basic types. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: mailutil appenddelete silently loses mail?
If by the other 20 megabytes you are referring to the difference between 53775404 and 31356329, that difference is probably in expunged messages which never got garbage collected because the expunge was always from a shared-access session. The way to test that is to expunge INBOX.head without multiple access. I bet that you'll find that it shrinks by that about that amount. The last 8 bytes in the internal header are the message UID. Newly delivered messages get a UID of 0, which causes a UID to be assigned the next time the mailbox is opened (as opposed to append). Otherwise, append would have to go to a lot more work. 3-Aug-2004 and 03-Aug-2004 are exactly equivalent. One happens when the date is provided, the other happens when the date is defaulted. It's not worth fixing. On Thu, 30 Sep 2004, Tim Mooney wrote: All- I have a vague recollection of reading that a bug in mailutil was recently fixed where mailutil would miss the last message in a folder when doing a `move' or `appenddelete', but I can't find any reference to that in 2004a and the 2004b dev doesn't include any kind of ChangeLog, so I don't know if I'm just dreaming... In any case, I've run into a strange situation with mailutil that seems similar to the problem I might have imagined: $ ls -al INBOX -rw---1 mooney sysadmin 55801103 Sep 30 12:02 INBOX $ file INBOX INBOX: MBX mail folder $ mailutil check INBOX Unable to find CRLF at 53775404 in 64 bytes, text: From [EMAIL PROTECTED] Fri Aug 13 12:54:08 It's corrupt, we have utilities to deal with that (all of which use mailutil to some extent). I split the folder at the corruption point, into: $ ls -al INBOX. -rw---1 mooney sysadmin 53775404 Sep 30 12:08 INBOX.head -rw---1 mooney sysadmin 2025699 Sep 30 12:08 INBOX.tail I check INBOX.head, which should now be a valid MBX-format mailbox: $ mailutil check INBOX.head No new messages, 262 total in INBOX.head I create a new, empty mailbox in MBX format: $ file INBOX INBOX: MBX mail folder $ mailutil check INBOX No new messages, 0 total in INBOX Now I appenddelete the messages from INBOX.head into INBOX: $ mailutil appenddelete INBOX.head INBOX $ echo $? 0 $ mailutil check INBOX 262 new message(s) (0 unseen), 262 total in INBOX $ ls -al INBOX -rw---1 mooney sysadmin 31356329 Sep 30 12:08 INBOX Ok, where did the other roughly 20 Megabytes go? If I compare a before and after, by viewing the 53 MB INBOX.head and the 30 MB INBOX in two different pine windows, the message index shows the exact same messages, in the same order, and with the same size displayed. If I pull off the 2K header from each mailbox so that I can use ``diff -u'' on them (it doesn't like the null padding), I see that the `appenddelete' has changed each of the MBX index lines, so that the last eight characters are all zeros: -27-Nov-2002 00:30:04 -0600,1245;0009-0003 +27-Nov-2002 00:30:04 -0600,1245;0009- It also appears to have rearranged the order that some of the messages are written into the file, so that it's very difficult to find what's truly missing. Any suggestions to try figure out what the missing 20 MB is, and what may have happened? Two asides: - I've noticed that the MBX index line, 03-Aug-2004 16:06:06 -0500,4355;8003-0ee6 sometimes has a date that is zero-padded, and sometimes its space-padded: 4-Aug-2004 00:02:58 -0500,696;8003-0eed Why is that? - It would be useful to have a `version' command available from within mailutil, so you can see some kind of version info, so you can tell what imapd kit mailutil came out of. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html -- -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: mailutil appenddelete silently loses mail?
On Thu, 30 Sep 2004, Tim Mooney wrote: What's the best source for information on the MBX internal header? Some information is in the IMAP FAQs: http://www.washington.edu/imap/IMAP-FAQs/index.html#7.15 I think it's time I learn the signficance of the various bytes in the internal header after the ;. The 12 bytes between the ; and the - are the flags mask; 8 hex digits of keyword flags and 4 hex digits of system flags. The bit definitions are in the source code. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Unable to create TCP socket: Protocol not supported (errflg=1) in Unknown on line 0
Unable to create TCP socket: Protocol not supported does come from the c-client library; the rest (starting with the errflg stuff) must be coming from Horde. What operating system are you running? Did you build imap-2004a yourself? Is there any possibility that it could have been built with IPv6 support (IP=6 in the make command line) but run on an IPv4 only system? Have you tried imap-2004b? This is currently available in development snapshots: ftp://ftp.cac.washington.edu/mail/imap-2004b.DEV.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: mail_fetch_flags() problems???
On Sat, 25 Sep 2004, Shawn Walker wrote: So heres the situation, i call mail_fetch_flags() on 1:* to have c-client fetch flags on all messages in a folder, I then loop over each message number and call mail_elt() on it, and use the returned info for getting my information about a messages flags. This works great the first time through. However, if I do this again after modifying the flags on the server (for instance, \Seen), the return from mail_elt() still has the old flag info Either you have not modified the flags on the server, or the server is broken. (despite having called mail_fetch_flags() again). Calling mail_fetch_flags() again is a waste of network bandwidth. All it does is slow down your client. The IMAP protocol automatically updates flags on the client. Once the cache is loaded, it stays loaded and current. The *only*, and I do mean *only*, reason *ever* to call mail_fetch_flags() is if you intend to reference flags in your client without otherwise touching at the message. In that case, and that case *only*, the cache may not have been loaded. Calling mail_fetch_flags() on 1:* is generally a very bad idea. There is almost always a better way to do what you intend. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: tmail and account verification
On Fri, 24 Sep 2004, Frode Nordahl wrote: I'd like tmail to check if a account is expired before attempting to deliver mail to it. tmail does not currently do this. I feel that the harm to a site which does not want it done is too great, so I don't think that I will make this change. Account expiration is generally a point at which user access to an account is shut off, and is not necessary the same as account termination. Since you have tmail sources, you are welcome to make the change in your own copy of tmail. Is it really necessary for tmail to make such verbose logs under normal operation? :-) The level of tmail logging is controlled by the syslog configuration file for the LOG_MAIL facility. Most of the tmail babble type messages are at LOG_INFO level (which is also the level at which sendmail babbles), with warnings and errors at LOG_WARNING or LOG_ERR. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: 64-bit problems with c-client imap2004a
On Wed, 22 Sep 2004, Chris Ross wrote: env_unix.c:1633: warning: cast to pointer from integer of different size env_unix.c:1636: warning: cast from pointer to integer of different size ..type of warnings. The ones listed there I doubt are terribly important, but some of them may very well indicate problems. You can disregard these warnings entirely. A few pedantic C compilers get upset at the use of void* as a bucket to hold an arbitrary cell, even though this is often the only way to do something *and* the programmer indicated his intent with an explict cast (which supposedly tells the compiler I know what I'm doing, damnit!). Particularly, tho, I've found a problem that doesn't produce an error. In tcp_unix.c, getsockname() is called, and the third argument given to is is a size_t*. However, on NetBSD, it calls for a socklen_t*, which is a pointer to a 32-bit value, and size_t is a long, and therefore 64 bits. Sigh. On some systems, it's an int* (and socklen_t is undefined). On some, it's a socklen_t*. And on some, it's a size_t* (and socklen_t is undefined). At UW, we have examples of all three; and there's no good way for the code to know what it is on the system being built. That's why c-client casts it to a void*. And on some systems, an int is 16 bits, and if getsockname() expects a pointer to a 32-bit cell it won't do the right thing either. There's simply no way to win on every possible platform. I suggest that the best thing to do is have the NETBSD osdep files redefine getsockname() as a jacket function into the real one. Take a look at the SCO osdep files for an example (e.g. how rename() gets redefined). Of course, that assumes that all NETBSD is 64 bit or at least follows the socklen_t* convention; if not then a new port has to be spawned off. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: smtp auth problem
The linkage.c module is where I put critically necessary initialization steps for c-client. Not all of those steps are obvious. If you link manually instead of using linkage.c, some things now (and in the future) will fail in unpredictable ways. I have already had incidents where I wasted a lot of time debugging someone's problem, only to discover that a critical linkage wasn't done because he lunk manually in his application instead of using linkage.c. If you want to remove some drivers, do so in the DRIVERS setting in the Makefile. DO NOT LINK MANUALLY!! On Thu, 16 Sep 2004, Niklas Fondberg wrote: Why? I don't want everything plus I need a small memory footprint... Mark Crispin wrote: Please do not link things manually. Please use linkage.c instead. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Build question
On Thu, 16 Sep 2004, Niklas Fondberg wrote: SSL and RSH are completely independent of each other. If your embedded device does not have RSH installed, then the RSH code is ignored. Is this a compile time or a runtime ignore? It's runtime. But I doubt that you'll save more than a trivial amount of memory. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Another ipop3d POP_PROXY mode problem
It should suffice to check in the BYE case for (state != UPDATE), and don't do the Mailbox closed action if (state == UPDATE). -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: smtp auth problem
On Wed, 15 Sep 2004, Niklas Fondberg wrote: I'm not able to get to mm_login when I call smtp_open to a smtp server that needs authentification. Did you #include linkage.c early in the main() function of your program? This is required. Have you made modifications to the c-client library? If so, what? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: ipop3d kerberos port?
On Wed, 15 Sep 2004, Kai Lanz wrote: We're thinking of switching from our old qpopper to ipop3d. Our qpopper accepts kerberized connections on port 1109, kpop. Grepping the UW source doesn't turn up any references to 1109 or kpop; can ipop3d do authentication via kerberos? Yes. Does it do so over the plain POP3 port, 110? Yes. If so, would it be easy to modify to use 1109 instead? I don't know what the requirements of port 1109 are; nor in fact do I have any clue as to what kpop is that's any different from a POP server that either uses the KDB to do plaintext password authentication or supports SASL. If it's just a POP server with Kerberos, then it's just a matter of [x]inetd configuration and not ipop3d at all. If, on the other hand, there's a special undocumented command to authenticate with Kerberos, then you'll have to write code to support it. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: fatal: ?Bad msgno X in mail_elt, nmsgs = Y
On Tue, 14 Sep 2004, Brian Redman wrote:
What's the recommended way to guard against trying to access a message via
msgno that's greater than nmsgs.
Keep track of all mm_exists() and mm_expunged() events. That will
guarantee that at all times you know the number of messages in the
mailbox. Never send msgno 0 or a number greater than the number of
messages.
I currently check myStream-nmsgs but
occasionally when I mail_fetchenvelope(myStream, msgno) I get the fatal error
anyway.
You must be doing something wrong; because if you did that you would not
have the problem. Between the time you checked myStream-nmsgs and called
mail_fetchenvelope() you must have gotten a mm_expunged() event.
mm_expunged() events happen only at well-defined points.
Are you sure that you aren't doing something like:
if (msgno = myStream-nmsgs) {
. . .
mail_ping (myStream);
. . .
env = mail_fetchenvelope (myStream,msgno);
the point being that you called some other mail_xx() function between
your test and calling mail_fetchenvelope().
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
Re: patch to set ssh-command and ssh-path
I have adopted your proposed patch as-is. Thank you. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: ipop3d POP_PROXY mode poblem
Thank you very much for your suggestion. A similar change to the one that you propose will be in the next version of c-client. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Thread safety..
On Wed, 1 Sep 2004, Andy Fiddaman wrote: The application is threaded so I was looking to see how thread-safe the library is. The real issue is your C library. A common problem is that many C libraries do not have a thread-safe strtok (meaning that it keeps the state per-thread), select(), or host name routines. Many C library implementors weasel their way out of it by making you use other calls such as strtok_r(). In general, it looks as if it will be okay if I'm careful (e.g. don't manipulate driver parameters from a thread), It has been said that threads are the crack cocaine of programming; they are powerful, poorly-understood by many of their users, and have a substantial mythology. There is *nothing* wrong with altering a global in threaded code as long as you accept that that alteration affects every thread. This is a very useful attribute (beloved of those of us who wrote multi-forked code with shareable writable pages on TOPS-20). It is something that must be thoroughly understood; but it is not something to fear. In general, when you change a driver parameter, the desired effect is to change the global behavior of the driver. What this means in general is that if you want to change a driver parameter, you go ahead and do it. Usually, you'll be doing this at startup or under control of the user interface, instead of deep within some thread. but there are a couple of places where race conditions could occur. For example, there is code at the start of unix_header() which populates a global STRINGLIST if it hasn't been done before. This is an excellent example. That global STRINGLIST is global for a reason. It should be a global constant, but it's complex enough to need code to build it. The only concern is whether another thread can run and join that code while the STRINGLIST is being built. For this, you need to understand how your thread library works. If thread switching only happens on I/O, you are safe since the only thing that code does is assignment and malloc(). If the threads really are separate kernel processes running in the same address space (as in Linux), then a simple mutex will do the trick. Here's one that will build even on systems which don't have threading: static long lock = -1; . . . if (++lock) sleep (1); . . . protected code . . . lock = -1; It'll take over 100 years for the lock to overflow with that sleep() there, so it's alright to keep testing it. On the other hand, this may not work if prefix increment is non-atomic; the C specification implies that it is, but it makes no definite statement. I'm not adverse to adding this sort of a mutex to this and the other places that initialize globals that are intended to be constants once set. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Setting X-Flag in the header
On Tue, 31 Aug 2004, Shawn Walker wrote: How would I go about setting a X-Flag in the header? The setextendedheaders() apparently been nixed. I've never heard of setextendedheaders(). What do you mean by setting a X-Flag? Do you mean adding a header line in an outgoing (to SMTP or NNTP) message that you are composing? Or, do you mean adding an X-Flag header line to a message in the mailbox? -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: imapd 2004a crashing frequently
This is a known problem, and is fixed in the imap-2004b development snapshot. If it makes you feel any better, this crash only happens with a session which is already in the process of terminating; it doesn't affect an active session. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Supporting a very large number of users on a Linux machine
If you need me to elaborate on Rich Graves' reply, please let me know. You don't really need to go as far as black box mode; but the docs/CONFIG file should definitely be at the top of your reading list. The real problem that you have to face is security. imapd uses the UNIX filesystem to authorize file access. If you allow other-user access at all you have to have as many unique access tokens as there are unique users. Otherwise joe would have free access to sally's files, just because joe and sally have the same UNIX UID. If you disable other-user access in imapd (read about restrictBox), then you don't have to worry about this as much. Of course, then you have to trust imapd to make the right checks in all circumstances and that no clever hacker can figure a way around it. I personally believe in 32-bit UNIX UIDs. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: Help Running UW-IMAPD Under Cygwin
The first thing that you must realize is that UW imapd was not developed for Cygwin; it was developed for UNIX. Cygwin gives a UNIX-like environment under Windows, but it is not UNIX. This fact is important in understanding various issues. I should also note that there is a native Windows build. For those who want to use UW imapd under Windows, I recommend using the native build rather than Cygwin. Some things are known not to work under Cygwin, because Cygwin is not a complete/100% accurate implementation of UNIX. On Sun, 29 Aug 2004, overbored wrote: (1) I can log in, but I have no idea where the mail is. I can do an 'a examine inbox' (meaning 'inbox' exists, since 'a examine asdf' doesn't work), but where exactly is this inbox? It is very possible that no file for INBOX exists. In that case, INBOX (which always exists in IMAP) is empty. UW imapd will notice when an INBOX file is created and messages are put in it, and then the IMAP INBOX will go non-empty. Normally, an INBOX in UNIX will be the user's traditional UNIX format mailbox file in spool directory (e.g. /var/mail). This is one of those not complete/100% accurate issues that I alluded to above. An INBOX can also be one of several format-specific files (read the documentation about various mailbox formats); however note that only the mbx driver has been made to work under Cygwin and there are known Cygwin issues which break the other drivers. Perhaps at this point you're starting to recognize why I suggest using a real UNIX system, or the native Windows build, rather than Cygwin... 'a list *' seems to recursively list everything under my home dir. This is normal behavior, and is discussed in the FAQ. (2) I'd like to migrate my existing mail store (mbox format) to this IMAP. From what I've read, it seems that UW-IMAP also stores its messages in mbox format. But there's also a program called tmail to inject messages into IMAP. Can I just copy over my existing mbox files to wherever IMAP stores the messages Yes. tmail is for mail delivery. What you're doing is copying messages. Note that the native Windows build can also read traditional UNIX mailbox format; although it would be better if you transfer those files in ASCII mode so they are in CRLF format. (3) I would like to have mail coming from various POP accounts going into my IMAP mailboxes. I have learned how to use getmail; if I would like to use this with UW-IMAP, do I need to configure it to use tmail, or directly write to the mbox files? I don't know anything about getmail. I've read somewhere about locking issues; is this the reason why tmail is needed? tmail is for mail delivery (being called from sendmail or whatever SMTP server you are using). That is not the same as copying mail from a POP server. The locking issues are that Cygwin implements locking like Windows (surprise!) rather than like UNIX. The native Windows build knows about this, and the native Windows drivers use Windows style locking. The UNIX build, which is what Cygwin uses, thinks that locking is UNIX style, but in actuality Cygwin just has a subroutine which looks like UNIX style but actually is Windows style. Not the same thing. The mbx driver has been kludged to work around the subtle differences, but the other drivers have not. (4) (This is more of an IMAP protocol question.) I glanced at the RFC for IMAP. Is there the concept of views/search folders/dynamic filters? It seems that the 'mailbox' concept is like a folder, in that a message can only belong to one. The closest thing I could find was the attribute, but it was intended for things like 'read', etc.; can this be used for the above purpose, or is IMAP not a good protocol to use for searching? I don't understand this question. Please rephrase it, and avoid the use of the word folder which has imprecise meaning. Use the term mailbox (a name that holds messages), directory (a name that holds other names), or dual-use name (a name that is both a mailbox and a directory). - the 'root' user doesn't exist on my system (had to use SYSTEM) Note that the UNIX version of UW imapd must be run as root and must be able to do a setuid to the target user. This, of course, has no meaning under Cygwin. Cygwin has a kludgy thing called cygwin_logon_user() which jackets into the Windows impersonation functionality which is actually quite different. Once again, the native Windows build knows about all of this, and does the right thing. As the author of UW imapd, I strongly recommend against using Cygwin as a platform for running it. Instead, you are best off running imapd on a real UNIX system. If you must use Windows, you are better off using the native build and dealing with the necessary customizations for your system, rather than hoping that Cygwin will do the right things for you. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public
Re: query all IMAP folders via POP3
On Sat, 21 Aug 2004, Florian Effenberger wrote: is there any option or POP3 server that has the ability to query all IMAP folders via POP3? The short answer is no. POP3 does not have that capability. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re: query all IMAP folders via POP3
On Sat, 21 Aug 2004, Florian Effenberger wrote: Any chance that the UW IMAP pop proxy will get this functionality? There's always a chance that anything can happen. However, some chances are extremely small; and this is one of them. An attempt to make POP3 support multiple IMAP mailboxes is like trying to make an abacus execute a large C program. Yes, with enough contortions and hard work, it can be done. But it's a pointless exercise. The work required (both in software development) and in runtime (each time the POP3 server is run) is substantial. A better use of such resources is in developing an IMAP client. POP3 should be used for the purposes that POP3 was designed to accomplish. If you have IMAP needs, you should use IMAP. -- 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 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: Question about mail_partial_body/text
On Thu, 5 Aug 2004, Crispin Olson wrote: I've dug around and found a few comments and even some examples of how to use these functions. However, it begs the question - why do these functions need callback drivers? Why cant they return the data in a string like the mail_fetch... functions? The original intent of partial fetching was to permit resource-limited clients to do so without requiring a potentially huge memory buffer. You don't generally want to do a fetch-as-string for a 600MB video file. I don't think that a callback function is all that hard to write. -- 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: 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.
