Re: possible imaprc.txt erratum
Mark, 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). I see your point. Empty means empty in the sense of contains zero bytes rather than contains zero messages (since it describes a file rather than a mail folder). I was thinking that the passage neglected to specify what happens if the mail folder file INBOX does not exist, but then I realized that I was making another subtle misinterpretation. I think I grasp now that INBOX is the imap abstraction equivalent to the mail folder INBOX in $HOME or, when this does not exist, the incoming mail spool file. But still, even with this understanding, what happens if there is no INBOX at all? Mark
Re: set new-folder-format same-as-inbox broken?
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. Sorry about the false alarm. For some reason I can't reproduce the problem anymore either (still using Mozilla as client). The only difference I can point to between now and then is an update from Mozilla 1.7.6 to 1.7.7, but this seems like an impossible explanation. I'll assume that I made a mistake (several times) during my testing. Maybe the imap connection was persisting during the various versions of c-client.cf and the file is only read once when imapd starts (invoked by inetd). Still, I am puzzled because I restarted Mozilla several times intending to rule out this possible effect. Mailutil create is not affected by set new-folder-format same-as-inbox, but I think this is by design. Mark
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: possible imaprc.txt erratum
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. Now that you mention it, I had noticed a number of almost supernatural properties in imap. Probably because the documentation is otherwise so thorough, the omission of this case, slight as it is, sort of stands out.
set new-folder-format same-as-inbox broken?
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. (New folders are still in the system (Linux) default of traditional Unix) On the other hande set new-folder-format mbx works as expected. Here is my /etc/c-client.cf: I accept the risk # uncomment this if you want plaintext logins w/o ssl (a bad idea) set disable-plaintext nil # uncomment this if you want $HOME/.imaprc to work for individual users # set allow-user-config T # don't allow people to use .. and ~ in mailbox expressions (cleaner) # set restrict-mailbox-access all set new-folder-format mbx regards, Mark -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
possible imaprc.txt erratum
In the following passage of imaprc.txt, shouldn't the sentence If INBOX is empty, it defaults to system standard. read If INBOX does not exist, it defaults to system standard. 1) set new-folder-format sets what format new mailboxes are created in. This also controls default delivery via tmail and dmail. a) set new-folder-format same-as-inbox Folder is created using the same mailbox format as INBOX. If INBOX is empty, it defaults to system standard. b) set new-folder-format system-standard This is the default. Folder is created using the wired-in system standard format, which on most UNIX systems is ordinary UNIX /bin/mail format. On SCO systems, this is MMDF. c) set new-folder-format Folder is created using the given driver name, e.g. mbx, unix, mmdf, etc. regards, Mark -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
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.
What does CLIENT BUG in result of STATUS operation mean?
Hi, Can someone tell me what the CLIENT BUG references mean in the status report? 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): 4/16/2005 10:55:05 AM: 0005 STATUS INBOX (MESSAGES RECENT UNSEEN UIDNEXT UIDVALIDITY) 4/16/2005 10:55:12 AM: * NO CLIENT BUG DETECTED: STATUS on selected mailbox: INBOX 4/16/2005 10:55:21 AM: WARN - CLIENT BUG DETECTED: STATUS on selected mailbox: INBOX 4/16/2005 10:55:30 AM: * STATUS INBOX (MESSAGES 150 RECENT 0 UNSEEN 0 UIDNEXT 247 UIDVALIDITY 1108742917) 4/16/2005 10:56:53 AM: 0005 OK STATUS completed Thanks very much. This certainly looks pretty confusing to me, but I' m just getting started writing a client using c-client. Mike -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
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?
Thank you very much, Mark. This is exactly the information I was looking for. I am just learning to understand c-client, and, although I have read the various doc files many times, especially the internal.txt one, there are many aspects of the operational use of c-client that I do not yet understand. Your help is great, and I greatly appreciate your clear responses. Many of the commands I am issuing at this time are exploratory; since I don't yet understand the proper use of imap (I was only a user and server jock with respect to imapd), I am still exploring. I appreciate the easy callbacks that c-client provides for this kind of information because it means I can see (and display) all the imap command traffic in both directions. Hence the questions. I will continue asking questions because I am not capable of writing code I don't understand the why and wherefore of. I noticed there are a number of functions exposed in mail.h that are not documented in internal.txt. I don't want to bother you unnecessarily, but you may get questions about some of these functions from time to time, if they seem to be useful to my approach. 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? Thanks for your quick response. You help is invaluable to me. Mike Mark Crispin wrote: 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: What does CLIENT BUG in result of STATUS operation mean?
Thanks Mark. When I look at the server logs for Thunderbird or Outlook, I never see more that one IMAP logon at a time. That also goes for all the users on our production server, although they are nearly all either Outlook or Thunderbird, with maybe an occasional Eudora thrown in for good measure. In my own case, on one account, I have maybe 30 or more mail folders, on another maybe 6 or 7. Yet I never see these IMAP clients logging on more than once simultaneously. Now, they don't use c-client as far as I can tell. Does this mean they are operating in a different way ? Something roughly equivalent to 1 connection, multiple mailstreams? For the moment, I expect to use just an inbox and a sent folder, so I only have two mailboxes to monitor/operate, and that may not even be simultaneously. But of course I'm just getting started. I 'd rather not be obliged to re-design my system later, so I need to at least consider the implications. If this becomes an issue, is it possible/useful/interesting to separate the connection from the mailstream? Or is uw-imap effective in this environment? (BTW, I have no intention of changing my mail server under any circumstances) unless forced to, and that would be kicking and screaming. Mark Crispin wrote: 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: What does CLIENT BUG in result of STATUS operation mean?
On 04/16/2005 07:44:18 PM, Mike Schmidt wrote: Thanks Mark. When I look at the server logs for Thunderbird or Outlook, I never see more that one IMAP logon at a time. That also goes for all the users on our production server, although they are nearly all either Outlook or Thunderbird, with maybe an occasional Eudora thrown in for good measure. In my own case, on one account, I have maybe 30 or more mail folders, on another maybe 6 or 7. Yet I never see these IMAP clients logging on more than once simultaneously. Now, they don't use c-client as far as I can tell. Does this mean they are operating in a different way ? Something roughly equivalent to 1 connection, multiple mailstreams? There are many clients that open several concurrent connections. Mozilla/Thunderbird allows limiting number of concurrent IMAP connections (Server Settings/Advanced) and often uses just one by chosing to SELECT mailboxes frequently and doing extensive client-side caching. I guess the reason for this kind of model was that mozilla was designed to work efficiently in offline imap mode which obviously is not able to take advantage of many concurrent connections anyway. As Mark wrote, it's a tradoff. If you have relatively short-lived connections or your server's has some database-based backend with very fast SELECT operation, opening one/very few connections may be a good idea. If you need to interactively watch several mailboxes for modifications, keeping separate connections open may be better. (BTW, some imap servers allegedly limit number of concurrent connections for the same user). For the moment, I expect to use just an inbox and a sent folder, so I only have two mailboxes to monitor/operate, and that may not even be simultaneously. But of course I'm just getting started. I 'd rather not be obliged to re-design my system later, so I need to at least consider the implications. If this becomes an issue, is it possible/useful/interesting to separate the connection from the mailstream? IIRC, each c-client mailstream opens a separate connection. Pawel Or is uw- imap effective in this environment? (BTW, I have no intention of changing my mail server under any circumstances) unless forced to, and that would be kicking and screaming. Mark Crispin wrote: 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.
location of uid of a message in a mbx folder
Hi All, I'm trying to track down where message uid is encoded in a message in a mbx mail folder? Darren -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Re: when ought messages to get moved from spool to user's mbx INBOX?
I have a question, or maybe I just need some advice. Consider this situation please: -There's a user called info. The purpose of the user is to receive mail that will end up in a shared mailbox that members of a group info can read and write to. -Postfix delivers messages to /var/spool/mail/info (traditional unix style text file) -An mbx INBOX exists in /home/info (created by mailutil create #driver.mbx/INBOX) -Another user, Sam, has a symbolic link: /home/sam/mail/info pointing to /home/info/INBOX. ... ... ..if Sam uses imap to subscribe to the symbolic link and read messages, this act does NOT result in magically moving new messages from /var/spool/mail/info /home/info/INBOX. (My ugly workaround for the time being is a cron job that does the moving with mailutil.) Thanks to Eduardo Chappa for explanation and discussion of better strategies to get incoming mail into an INBOX meant to be shared and accessed by multiple users at the same time. Here's a summary, in case someone else is trying to do the same thing. The behavior of c-client which moves mail from the incoming spool file to INBOX in the home directory is triggered by accessing the spool file. It therefore makes perfect sense that reading mail from a symbolic link pointing to the INBOX in the home directory won't trigger moving. A better strategy uses procmail and dmail to allow postfix to deliver incoming mail to the mbx INBOX. (Postfix by itself does not know how to write to mbx files.) I installed the dmail binary built from the imap kit into /usr/bin. I then made .forward and .procmailrc in /home/info. The .forward contains: |/usr/bin/procmail The .procmailrc contains: :0 fw |/usr/bin/dmail +INBOX As Mark Crispin pointed out later, postfix can also use tmail to deliver mail to mbx mailboxes (without having to use procmail). I have not been able to evaluate yet whether the tmail approach would be better suited to my situation.
symbolic links to mailboxes and locking
Is it safe for several users to be accessing the same mbx mailbox via different symbolic links pointing to that mailbox? Assume that all users are doing this with c-client software, or even that all users are using imapd. -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
simultaneous access to incoming spool file by c-client and postfix
Please consider 2 situations where messages are moved from spool files into mbx INBOX files in users home directories: A. c-client software automatically moves mail when software accesses incoming spool file. B. Someone explicitly invokes mailutil appenddelete. The question is: Can corruption of the incoming spool file arise due to conflicts with software (such as postfix) that is delivering mail to the spool file? If so, what measures should be taken to prevent this from happening? Thanks. -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
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.
caching and mailbox synchronisation with c-client
Hi, I'm writing a headless imap client using c-client on WindowsXP. I have interfaced to all the mail functions and can successfully read mail messages from my uw-imap server (linux). Since the mail storage is handled by another application, with which my client communicates. The c-client code currently has no way of knowing what has already been downloaded. In such a case, what do I need to do to keep track and do proper synchronisation with the imap server? The imap server is also accessed by other applications (webmail, existing email clients like Outlook, Thunderbird,etc). I have never wirtten an imap client before, so I don't know whether I should be downloading all the headers every time, and ask the mailstore to compare, or do I need to write a cachemanager, etc. How do I determine that some messages have been deleted and expunged between two sessions, for example? If it makes any difference, the imap server is runnng with mbx format mailboxes. These mailboxes can be quite large, sometimes into the 100Mb+ range, with messages numbering in the thousands. I appreciate any ideas that might help. Hopefully some of you have encountered this situation before, and have asome good ides to suggest. Thank you for any help you might be able to provide. Mike -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
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.
[announce] mbx-repair script
All- This relates more to the mbx-format supported by UW's imapd than to c-client, so I'll be brief. We make extensive use of mbx in our environment, and we occassionally run into corrupt mailboxes. Like many other sites, we've developed an in-house tool for automating some of the repair process with mbx-format mail folders. In the hopes that someone else will find it useful, we're making our mbx-repair script available. The script is written in perl, and uses a perl module I wrote, which I'm calling IMAP-UW-Mailutil, to talk to the `mailutil' program. It's mailutil that does all the work. Both the script and the perl module are available at ftp://ftp.nodak.edu/pub/ndsu/svg/mbx-repair I would consider both the script and the module to be beta quality. We've been using both in our environment for several months without problems, but there's plenty of room for improvement in both. Both are licensed under the same license as perl itself. Comments, suggestions and feedback welcome! 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 --
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.
Problem with MBX INBOX
Folks, 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. Connecting to the INBOX does not result in any error messages so I don't really have anything to go on to make a manual repair. There doesn't appear to be a problem with the message immediately prior to the first one being displayed. Any advice on how to proceed will be gratefully received. Thanks, Clive McDowell Information Services The Queen's University of Belfast -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Re: Problem with MBX INBOX
Does mailutil check mailbox comes back reporting no errors and the correct number of messages? John Landamore School of Mathematics Computer Science University of Leicester University Road, LEICESTER, LE1 7RH [EMAIL PROTECTED] Phone: +44 (0)116 2523410 Fax: +44 (0)116 2523604 Folks, 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. Connecting to the INBOX does not result in any error messages so I don't really have anything to go on to make a manual repair. There doesn't appear to be a problem with the message immediately prior to the first one being displayed. Any advice on how to proceed will be gratefully received. Thanks, Clive McDowell Information Services The Queen's University of Belfast -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Re: imapd for MacOS X - Authentication errors
Dear Mark,
Thanks for your answer. I've figured out the authentication problems, and
it has to do with PAM. MacOS 10.3 (Panther) uses PAM for all of its
authentication, quite different from 10.2 (Jaguar).
So in addition to starting the imap service on port 143 (and imaps on 993),
which I also hadn't been doing before), I had to add a file 'imap' to
/etc/pam.d/. Something like:
# imap : auth account password session
auth required pam_nologin.so
auth sufficient pam_securityserver.so
auth sufficient pam_unix.so
auth required pam_deny.so
account required pam_permit.so
password required pam_deny.so
session required pam_uwtmp.so
After this authentication worked, no matter if I compiled with SSLTYPE=unix
or SSLTYPE=nopwd.
I still have problems with the SSL certificate being validated, but that's a
different question for a different mailing list.
I found this page very helpful: http://www.theatrain.net/pantherimaps.html.
Thanks again!
--Matt
On 4/7/05 2:33 PM, Mark Crispin [EMAIL PROTECTED] wrote:
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.
--
Matthew Leingang
Preceptor in Mathematics
Harvard University
URL: http://www.math.harvard.edu/~leingang/
vCard: http://www.math.harvard.edu/~leingang/vCard.vcf
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: Problem with MBX INBOX
Mark Crispin wrote: 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. Mark, thanks - that was exactly the problem. This user seems to have a habit of leaving several sessions open. I guess she hasn't run an exclusive session for a while. Once forced to do so the inbox space was recovered. Clive McDowell
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.
rfc 3348 (CHILDREN extension) support?
Are there any plans to add RFC 3348 support to imapd? I'm currently
trying to improve performance in Horde IMP 4.x when accessing a
UW-IMAP server. IMP does 'LIST #shared/*' and then imapd returns a
huge list of shared folders, even though the user doesn't have access to
most of those folders.
C: a01 LIST #shared/*
S: * LIST (\NoSelect) / #shared/
* LIST (\NoSelect) / #shared/survey
* LIST (\NoSelect) / #shared/exec
* LIST (\NoSelect) / #shared/assembly
* LIST (\NoSelect) / #shared/senate
* LIST (\NoSelect) / #shared/mstu
* LIST (\NoSelect) / #shared/nct
...
a01 OK LIST completed
Our directory layout looks like this:
$ ls -ld /sharemail/shared/{,miles,admin}
drwxr-xr-x 497 imapshar staff 16384 Apr 7 18:30 /sharemail/shared/
drwxrws--- 2 imapshar miles 4096 Apr 7 15:07
/sharemail/shared/mile/
drwxrws--- 2 imapshar admit 4096 May 28 2003
/sharemail/shared/admit/
I'm not in any of these groups so I'll never have access to any
mailboxes within those directories. I'd like to have imapd not bother
returning those mailboxes at all. From playing with Cyrus imapd, which
does supprt RFC 3348, they seem to implement this behavior.
Looking at the imapd source, src/osdep/unix/dummy.c, around line 280,
seems to be the place to modify this behavior. After checking that an
object is a directory, I can check that the user actually has
permissions on the directory. Am I on the right track?
Cheers,
--
Matt
--
--
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/c-client-list.html
--
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?
Mark, Thanks for the quick response and the clarification. The way we organized our shared folders a user will never have access to a child mailbox is they don't have access to the parent and they would never create folders in #shared. Am I correct in that we'd want to modify dummy_list_work() to implement this? 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).
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.
mh_header performance patch
I read my MH mail from two clients: Emacs MH mode, directly from the MH
dirs, and Mozilla via the UW IMAP server. The IMAP server frequently
re-reads my mailboxes, which are sometimes large (e.g. 4k, 6k messages),
and it was taking a long time. I found that the routine mh_headers
always reads the entire message no matter how long it is and always does
strcrlfcpy on the entire body, while I certainly won't be requesting all
the bodies in the client. I felt it is doing unnecessary work, both I/O
and CPU.
I made a change so that mh_headers reads only the beginning of each
message file in 4kb chunks until it reaches the end of headers. I
reorganized the code a bit, to avoid duplication between mh_headers and
mh_text which requires both headers and body. Empirically, there tends
to be not more than 3kb of headers in my messages, so 4kb seems like a
good compromise. I didn't make it configurable, just hardcoded 4096.
After the change, folder scan time for 6k messages went down from 20+s
to ~13s on a dual CPU Sunblade-2500 running Solaris 8, with Mozilla
1.7.3 and imapd running on the same machine. Everything seems to work. I
verified with debug logging that I actually do go through the
header-only branch.
diff -c patch attached. Please feel free to adjust as necessary.
--Michael Klepikov
*** imap-2004c1.klm/src/osdep/unix/mh.c Thu Mar 24 15:43:50 2005
--- imap-2004c1/src/osdep/unix/mh.c Thu Mar 24 15:12:49 2005
***
*** 565,580
if (mail_elt (stream,i)-sequence) mh_header (stream,i,j,NIL);
}
! /* MH mail fetch message header
* Accepts: MAIL stream
*message # to fetch
*pointer to returned header text length
*option flags
* Returns: message header in RFC822 format
*/
! char *mh_header (MAILSTREAM *stream,unsigned long msgno,unsigned long *length,
!long flags)
{
unsigned long i,hdrsize;
int fd;
--- 565,581
if (mail_elt (stream,i)-sequence) mh_header (stream,i,j,NIL);
}
! /* MH mail fetch message header and (optionally) text
* Accepts: MAIL stream
*message # to fetch
*pointer to returned header text length
*option flags
+ * a boolean flag whether or not need msg text
* Returns: message header in RFC822 format
*/
! char *mh_msg_fetch (MAILSTREAM *stream,unsigned long msgno,
! unsigned long *length, long flags, int need_text)
{
unsigned long i,hdrsize;
int fd;
***
*** 585,591
*length = 0;/* default to empty */
if (flags FT_UID) return ;/* UID call impossible */
elt = mail_elt (stream,msgno);/* get elt */
! if (!elt-private.msg.header.text.data) {
/* purge cache if too big */
if (LOCAL-cachedtexts max (stream-nmsgs * 4096,2097152)) {
mail_gc (stream,GC_TEXTS);/* just can't keep that much */
--- 586,593
*length = 0;/* default to empty */
if (flags FT_UID) return ;/* UID call impossible */
elt = mail_elt (stream,msgno);/* get elt */
! if (!elt-private.msg.header.text.data ||
! (need_text !elt-private.msg.text.text.data)) {
/* purge cache if too big */
if (LOCAL-cachedtexts max (stream-nmsgs * 4096,2097152)) {
mail_gc (stream,GC_TEXTS);/* just can't keep that much */
***
*** 608,634
LOCAL-buf = (char *) fs_get ((LOCAL-buflen = sbuf.st_size) + 1);
}
/* slurp message */
! read (fd,LOCAL-buf,sbuf.st_size);
/* tie off file */
! LOCAL-buf[sbuf.st_size] = '\0';
! close (fd); /* flush message file */
/* find end of header */
! for (i = 0,t = LOCAL-buf; *t !(i (*t == '\n')); i = (*t++ ==
'\n'));
/* number of header bytes */
! hdrsize = (*t ? ++t : t) - LOCAL-buf;
! elt-rfc822_size =/* size of entire message in CRLF form
*/
! (elt-private.msg.header.text.size =
!strcrlfcpy (elt-private.msg.header.text.data,i,LOCAL-buf,
! hdrsize)) +
!(elt-private.msg.text.text.size =
! strcrlfcpy (elt-private.msg.text.text.data,i,t,
! sbuf.st_size - hdrsize));
/* add to cached size */
! LOCAL-cachedtexts += elt-rfc822_size;
}
*length = elt-private.msg.header.text.size;
return (char *) elt-private.msg.header.text.data;
}
/* MH mail fetch message text (body only)
* Accepts: MAIL stream
--- 610,680
LOCAL-buf = (char *) fs_get ((LOCAL-buflen = sbuf.st_size) + 1);
}
/* slurp message */
! if (need_text) {
! /*syslog (LOG_ALERT,Fetching msg with text #%ld, msgno);*/
! read (fd,LOCAL-buf,sbuf.st_size);
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.
Question about nested folders..
Can uw Imap (c-client) create nested folders? How do I do this? I read, somewhere, that this required using the .mbx format for mailboxes. So I recompiled imapd changing the default format to mbx. After some unpleasant experiences trying to get tmail to work with sendmail (can't figure out how to do it in sendmail.mc so did it directly in sendmail.cf - and, tmail has to be in /usr/bin (or the like) and can't be in /home/USER/..) Anyway, after doing all this, and successfully sending mail into sendmail which gets deposited in an INBOX in the user's directory, I still can get my client to create sub-folders that aren't at the top level. Is this possible? Thanks for your help - Yossie -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
followup on email about nested directories..
What I need to do, and am hoping that uw imap will do, is create subfolders within folders. So, for example, I could create folder X that contains messages and then put folder Y into it. I realize that both mbox and mbx formats are flat files and thus it seems UNLIKELY that this can be done. However, I am asking, IS THERE A WAY that I can do this with ANY uw imap supported options? THANKS - Joseph -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
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: followup on email about nested directories..
Mark Crispin wrote: 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. That is doable. Just deside on a special mailbox name to be the folders 'own' mailbox, let just call it mbox0 for now. If You try to access a folder as a mailbox, open folder/mbox0. If You try to access a mbox as a folder, just report it as empty. If someone try to save to a folder that's an mbox, create an temp folder. Move the mbox ther as tmpfolder/mbox0, move tmpfolder to the original mbox name, then proceed with the save. Will likly break other tools, but only if people actuly *us* the feature. 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. The ui isue is solwed long time ago. Standard 'treeview' with a + or arrow to expand a node, and some icon to select it. But this seems to be a matter of religion. Yeha, but I actuly have found a use for it. I sort mail in differnt folder, and for each folder mail older than one year in one folder for each year. Would clean up my folderlisting *allot* to make thes yearly folders subfolders to 'ther' mailbox. While keeping them in the same spot. /LaH
Re: followup on email about nested directories..
On Thu, 17 Mar 2005, Mark Crispin wrote: 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. Additionaly to this, you are not very supportive of the mh format, so it can be considered half-supported (can I say it that way). AFAIK Maildir supports what you want, there are add-on patches available, f.ex. here [1]. It seems to be actively maintained However I don't know how well it works. *t [1] http://www.math.washington.edu/~chappa/pine/info/maildir.html -- --- Tomas Pospisek http://sourcepole.com - Linux Open Source Solutions ---
win32 program use c-client cannot compile
Dear all, One of my win32 program use the c-client. When i compile, i get a lot of errors. e:\project\abc\ab\library\imap-2004c1\c-client\mail.h(471) : warning C4005: 'ERROR' : macro redefinition c:\program files\microsoft sdk\include\wingdi.h(98) : see previous definition of 'ERROR' e:\project\abc\ab\library\imap-2004c1\c-client\mail.h(760) : error C2059: syntax error : 'private' e:\project\abc\ab\library\imap-2004c1\c-client\mail.h(760) : error C2238: unexpected token(s) preceding ';' e:\project\abc\ab\library\imap-2004c1\c-client\mail.h(1052) : error C2059: syntax error : 'private' e:\project\abc\ab\library\imap-2004c1\c-client\mail.h(1052) : error C2238: unexpected token(s) preceding ';' I compile in VS 6.0 with PSDK installed. I can compile by using the makefile. -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
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.
c-client built in uudecoding?
Hi, After a cursory examination, I didn't see a uudecoding function anywhere in c-client; a co-worker swears there is one. Does c-client have uudecoding built in someplace? Charles -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
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.
c-client support for client certificates?
I'm trying to build up a Horde/IMP installation secured by using SSL certificates on both sides (server and client). I have no trouble using the client cert to authenticate to Horde, and I have no trouble using the client cert to authenticate _directly_ to Cyrus IMAP (which is obviously my IMAP backend). I'm running all this on Linux, using OpenSSL, and the IMAP toolkit was built using make slx with SSLTYPE set to unix.nopwd. What I cannot do (yet) is get IMP to pass the certificate it received from Apache along as part of the TLS negotiation when it tries to connect to the IMAP server. IMP uses the PHP imap extension, which in turn uses c-client (and yes, I'm running the latest c-client and PHP). The documentation on c-client is sparse... but I do see a mail_parameter setting for SSLCERTIFICATEQUERY. I cannot find any docs or examples that would show me what this is for, though, so I figured I'd ask here. 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? -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
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.
Problems with Google Mail SMTP
Hello all, Has anybody experienced problems using c-client on Google's SMTP server? I'm trying to send a message using c-client, and that's what I get: Log: SMTP SERVER BUG (invalid challenge): = Log: Can not authenticate to SMTP server: 334 = The hostlist I'm passing to smtp_open looks like this: smtp.gmail.com/ssl/[EMAIL PROTECTED]/smtp Any help is appreciated. Thanks. -- Best regards, Akmal mailto:[EMAIL PROTECTED] --- The hardest thing in the world to understand is the income tax. Albert Einstein. -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Re: mailutil transfer and bad messages
Hi, Also, when running test transfers, I am experiencing more weird error messages from mailutil, such as message contain NUL character. It seems that my users mailboxes contain a lot of crap. I remember, I had those a lot when I converted my old Unix mailboxes that had NeXTMail attachments in them. - Lars
Re: What to do with VERY large mailbox files?
Sorry, this is really back in time On Tue, 29 Apr 2003, Mark Crispin wrote: There are, indeed, other alternatives to flat-file and file/message formats. We are working on such an alternative in c-client, and hope to offer it soon (it's in testing here). Are there any news about this alternative format ? Thanks. -- Nicolas
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.
Hook scripts
Hi, How can I call a specific script when a user connects to the server or does any other stuff (like read or erase mail)? Thanks, JL -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
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 Tue, 1 Feb 2005 16:31:25 -0800 (Pacific Standard Time) Mark Crispin [EMAIL PROTECTED] wrote: MC On Tue, 1 Feb 2005, Vadim Zeitlin wrote: MC In theory I totally agree but in practice there is this broken server MC which doesn't support any other way to login except by using USER but still MC doesn't advertise it. It's clearly is a bug in server implementation and MC using USER is the only way to work around it. MC MC The server may not be broken. Unfortunately in this case it definitely is. It does not support neither TLS nor SSL (again, I should have written it from the beginning, sorry for omitting to say this). MC They may have an administrative policy that clients should use the SSL MC POP3 service (port 995) instead of unencrypted POP3 port 110; but for the MC benefit of old pre-SSL clients (which also would not use CAPA) it allows MC the USER/PASS commands. Ok, but if they [still] allow it, there mustn't be much harm in using it. I would understand if they only allowed SSL logins perfectly well, but they don't. In fact, they don't support them at all. MC Not at all. Did you try the SSL POP3 service? Yes. MC Speaking practically, what problems can I have if I still use USER even if MC the server doesn't advertise it? MC MC Doing so violates the specifications, and may very well violate the MC intentions of the POP3 server administrator. Again, not in this case. MC Worse, you may find yourself accused of behaving just like Microsoft in MC violating specifications for convenience. All too often the excuse of a MC necessary workaround has been offered as to why Outlook, etc. violates a MC specification. MC MC Still worse, if it's considered to be something that c-client does, I MC will be accused of behaving just like Microsoft. No thanks. :-) 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. So it's just going to be one more patch in my version of c-client and one more reason I can't use official (although at least in Debian case there are quite a few patches in it too) version of the library packaged by Debian, RedHat and so on. Not a big deal for me as there are other issues which are much more important for me which I had to patch in my version but I still can't prevent myself from thinking that all this is a big waste of effort and that having at least an option in c-client to enable the behaviour which makes sense to the users couldn't really be such a bad thing. Regards, VZ -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
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[4]: POP servers not advertising USER in CAPA reply
On Wed, 2 Feb 2005 10:25:09 -0800 Mark Crispin [EMAIL PROTECTED] wrote: MC Doing so is the type of behavior that Microsoft is often accused of doing: MC taking the expedient approach instead of the correct one. I find it sadly MC ironic that the open source community would even think of doing this, MC after all the years of Microsoft-bashing over this very issue. Mark, I'm exchanging sporadic mails with you for the last 9 years or so and during all this time I don't cease to be amused by your habit of bringing Microsoft policy into just about any kind of technical discussion. Could we please just leave Microsoft alone? I have no relation with Microsoft but I don't like being accused of Microsoft bashing groundlessly and, while I'm proud to be part of, I don't represent this mythical (but, judging from your description, nefarious) open source community in any way at all, so could we please just leave it at that? Thanks. MC It most certainly does violate the specification. How can you seriously state this in a case of a server which violates it in such way that it doesn't leave me any other choice but to do this? MC The minute your software is installed at a site which has such reclama, it MC also violates the intentions of the server administrator and adds to his MC (or her) headaches. Your software has no way of knowing that this is the MC case. But the user does. This is why I think that ideally there would be an option, e.g. a cclient callback to the main program which would allow it to decide -- presumably by asking the user -- whether to continue connecting. If there was a chance of this being ever integrated into c-client you can be sure that I'd provide a patch doing exactly this or whatever else you'd accept. However, when confronted to a total and absolute refuse to make any modifications at all to c-client from your part, I'm understandably reluctant to spend any amount of time on the code which will only create me additional maintenance headaches. MC I understand your point of view but you should realize, of course, that I MC am going to patch my c-client version (once again) because I can't tell the MC user with a straight face that I am not going to fix it when it's a whole MC of one line fix. MC MC In that case, honesty and morality requires that you also disclose to your MC user that your client is BROKEN and NON-COMPLIANT with the specifications, I do disclose that the version of c-client I use has been modified. MC If a site doesn't want to fix its server to comply with specifications and MC run your client, then your client isn't important to that site -- and that MC site shouldn't be important to you either. This is an amazing view of a problem which probably represented quite well the view of Internet in the early eighties. I may assure you however that when the server is run by a big ISP (as is the case here), no user, whatever his determination to use my client, can change their mind. And while I absolutely don't care about that site, I do care about my users which is the word which appears to never appear in your vocabulary at all. Regards, VZ -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Re: Re[4]: POP servers not advertising USER in CAPA reply
On 02/02/2005 07:52:25 PM, Vadim Zeitlin wrote: [snip] But the user does. This is why I think that ideally there would be an option, e.g. a cclient callback to the main program which would allow it to decide -- presumably by asking the user -- whether to continue connecting. If there was a chance of this being ever integrated into c-client you can be sure that I'd provide a patch doing exactly this or whatever else you'd accept. However, when confronted to a total and absolute refuse to make any modifications at all to c-client from your part, I'm understandably reluctant to spend any amount of time on the code which will only create me additional maintenance headaches. I am bit afraid of jumping right in into this heated discussion but I am going to give it a shot anyway. Working around bugs in somebody else's software is a tricky business: it's a judgement call and in case of a reference implementation (ok, c-client is a imap reference implementation, not pop3 but I can imagine many people may treat it as such) may cause an injustified impression that the bugs are not really bugs but just features. Assuming that you really have to work around this missing USER capability , I am not sure whether shifting responsibility of maintaining such modifications from you to the author of c-client is fair - he seemed to be reluctant to accept it, didn't he? I am sure that you would succeed convincing the right people (i.e. the writers of the buggy server) if you really wanted to, if you tried as hard as you try here. (have you tried?). It would be much better spent time - it would not only fix interaction with c-client but all the other standard conforming POP3 implementations. Pawel PS. my reading of RFC1939 is that it is ok to try USER but send PASS only if the server answered with +OK. Since the server in question has CAPA, it is a RFC2449-compliant server and the CAPA response is the authorative way of finding out which commands are available. While I do not see in RFC2449 an explicit statement that client MUST NOT try unadverstised commands, it is pretty much in the spirit of CAPA: if CAPA was not authorative it would serve no purpose.
Re: Re[5]: POP servers not advertising USER in CAPA reply
On Feb 2, 2005, at 22:55, Vadim Zeitlin wrote: MC In that case, the user can cancel his account at that ISP and find an MC alternative ISP which complies with the standards. How many users are going to do this? Or, more importantly, how many ISPs would do anything even if [s]he did? Many. I'm working at one of the largest ISPs in Norway, and we take pride in allways attempting to do things the right way, following standards, and generally being nice internet citizens. However, with your attitude towards the problem, no one will change. Is the pop server (or proxy) developed inhouse at the ISP, or is it from an external vendor? If it's an external vendor, go after them, and It'll eventually get in to the ISP through a security update. Either way there is probably someone sitting there that is just like your or me that would be very happy to learn about their honest mistake and correct it. It's not like ISP's or indeed ISV's are large chunks of grey matter, molded, never to change. (Although it might seem that way if you try to fight your way up from first line support or sales contacts). If everyone was to go about and put in band-aids to support everyone elses errors and misfeatures, we'll end up with a large, randomly misbehaving mess. You are free to do whatever you want, but I am glad to see that c-client will never grow such defects. Regards, Frode
Re[7]: POP servers not advertising USER in CAPA reply
On Thu, 3 Feb 2005 00:09:38 +0100 Frode Nordahl [EMAIL PROTECTED] wrote: FN Many. I'm working at one of the largest ISPs in Norway, and we take FN pride in allways attempting to do things the right way, following FN standards, and generally being nice internet citizens. My sincere congratulations. But you also should know how rare this behaviour is. And, moreover, you probably don't use server broken in such bad way anyhow because you know what you're doing. ISPs running the servers like this one do not. And in my experience they don't care. FN However, with your attitude towards the problem, no one will change. This attitude comes from experience. It may be lesser than that of MRC but it is not negligible. I'd rather spend time on writing code and improving my program (for which I don't have enough time now) instead of wasting time with that ISP. FN (Although it might seem that way if you try to fight your way up from FN first line support or sales contacts). It certainly seems this way to me. After trying to discuss with a few of them in the past I am not about to repeat this (painful) experience. Please don't forget that this is not my work and there is a limit to the time I can spend helping a user of my program. Quoting Mark Crispin: MRC Time and time again, I hear our server works with Outlook and MRC Thunderbird, therefore the bug is in Pine; so we're not going to MRC change our server or even look any further. If he (knowing who he is and all that) keeps hearing this, how many chances of success do I have? Let's be reasonable for a change... FN You are free to do whatever you want, but I am glad to see that FN c-client will never grow such defects. This would be a defect in a server. I still have no idea why allowing the user to override a badly broken server behaviour from his client is a defect. And so far I still see no reason for a user (knowing that he is careless enough to use POP, to use clear text auth, and to use such broken server) to not do it. And no other workaround, except for switching to another client. Regards, VZ -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
compile error
I'm trying to compile IMAP and I keep getting the following error: imap-2004c1]# make slx . . . ln -s ip4_unix.c ip_unix.c ln: `ip_unix.c': File exists make[3]: *** [onceenv] Error 1 make[3]: Leaving directory `/usr/local/imap-2004c1/c-client' make[2]: *** [slx] Error 2 make[2]: Leaving directory `/usr/local/imap-2004c1/c-client' make[1]: *** [OSTYPE] Error 2 make[1]: Leaving directory `/usr/local/imap-2004c1' make: *** [slx] Error 2 I've found that other users compiling this had no problem on fedora (using the slx as machine type). I'm using fedora 3. I figured dovecot was maybe conflicting, but I removed the dovecot package and same error comes up. I try other OS types (lnx, lrh) and still nothing. Any ideas? Thanks, mike
Re: compile error
On Tue, 1 Feb 2005, Kowal, Michael wrote: ln: `ip_unix.c': File exists ip_unix.c is a file that is made as part of the build. It should not exist when the build is started. Try doing a make clean and then try the build again. If you got your copy from a third-party, try getting it directly from the UW distribution at: ftp://ftp.cac.washington.edu/mail/imap.tar.Z -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
Re[2]: POP servers not advertising USER in CAPA reply
On Tue, 1 Feb 2005, Vadim Zeitlin wrote: In theory I totally agree but in practice there is this broken server which doesn't support any other way to login except by using USER but still doesn't advertise it. It's clearly is a bug in server implementation and using USER is the only way to work around it. The server may not be broken. They may have an administrative policy that clients should use the SSL POP3 service (port 995) instead of unencrypted POP3 port 110; but for the benefit of old pre-SSL clients (which also would not use CAPA) it allows the USER/PASS commands. The alternative is to not be able to login at all which may be correct (although in fact I don't see anything specifically forbidding use of USER in RFC 2449, it only states that its presence in CAPA response means that USER/PASS are supported but doesn't say anything about its absence!) but is absolutely useless. Not at all. Did you try the SSL POP3 service? Speaking practically, what problems can I have if I still use USER even if the server doesn't advertise it? Doing so violates the specifications, and may very well violate the intentions of the POP3 server administrator. Worse, you may find yourself accused of behaving just like Microsoft in violating specifications for convenience. All too often the excuse of a necessary workaround has been offered as to why Outlook, etc. violates a specification. Still worse, if it's considered to be something that c-client does, *I* will be accused of behaving just like Microsoft. No thanks. :-) AFAICS in the worst case the server will reply that command is not supported. This doesn't seem very bad to me. No. If it doesn't reject until the PASS command then the result is that passwords are sent in the clear. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum.
RE: 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 ?
Mark Crispin wrote:
On Thu, 27 Jan 2005, Patrick Bennett wrote:
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.
Yes, I tried exactly this.
...Did you use /authuser=, or did you try to use the * hack? 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.
I tried both actually. When using /authuser with Exchange I get the
error 'Can't do /authuser with this server.' I would assume this is
simply because Exchange 2003 only supports AUTH=NTLM *grumble* and in
fact, when connected via SSL, it doesn't advertise any AUTH method at
all!? (which seems odd to me)
I then set up a local test CommuniGate Pro server to try it. Using
mtest (with debug protocol on - and the sensitive flags in imap41.c
disabled) I get this:
-
Mailbox ('?' for help):
{localhost/user=postmaster/authuser=patrickb/novalidate-cert}inbox
[Trying IP address [127.0.0.1]]
* OK CommuniGate Pro IMAP Server 4.2.8 at test1 ready
[CommuniGate Pro IMAP Server 4.2.8 at test1 ready]
CAPABILITY
* CAPABILITY IMAP4 IMAP4REV1 ACL NAMESPACE UIDPLUS IDLE LITERAL+ QUOTA
ID MULTIAPPEND LISTEXT CHILDR
EN BINARY LOGIN-REFERRALS STARTTLS AUTH=LOGIN AUTH=PLAIN AUTH=CRAM-MD5
AUTH=DIGEST-MD5 AUTH=MSN
OK completed
0001 STARTTLS
0001 OK begin TLS negotiation
0002 CAPABILITY
* CAPABILITY IMAP4 IMAP4REV1 ACL NAMESPACE UIDPLUS IDLE LITERAL+ QUOTA
ID MULTIAPPEND LISTEXT CHILDR
EN BINARY LOGIN-REFERRALS AUTH=LOGIN AUTH=PLAIN AUTH=CRAM-MD5
AUTH=DIGEST-MD5 AUTH=MSN
0002 OK completed
0003 AUTHENTICATE PLAIN
+
{localhost/imap/user=postmaster} password:
cG9zdG1hc3RlcgBwYXRyaWNrYgAxMjM0
0003 NO SASL parameters are incorrect
%Retrying PLAIN authentication after SASL parameters are incorrect
0004 AUTHENTICATE PLAIN
+
{localhost/imap/user=postmaster} password:
--
...any ideas?
Thanks,
Patrick Bennett
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.
message status
I am using a Mac OS 10.3.x for a mail server (only about 25 clients). I used an application called Postfix Enabler to start the mail service. Postfix Enabler starts Postfix and loads the 2004 UW/IMAP release for pop3 and imap. All works well. My problem is with message status. Most of the clients check there mail on more than one machine, usually at work, then at home. Is there a way to make a message show as new when it is downloaded, no matter how many different computers it is downloaded to? Thanks for any help, Jim -- -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
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 --
building imap on aix 5.2
I have recently tried to build imapd on aix 5.2, build NOSSL a41. After installation, i cannot log into my imap account, I get some authorization type error. I have previously built imapd without incident! Mike Klein Manager of System Services Loyola University New Orleans 6363 St. Charles Ave. New Orleans, LA 70118 (504) 865-3470 -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
dynamic libraries imapd
Does imapd, versions prior to the 4.61, use dynamic linking for libraries, or, are the libraries included in the executable? I'm on aix 5.2 and use gcc to do the builds. The problem revolves around libiconv! With the ibm lib, it works, but other things don't. With the opensource version, other things work, but, imapd doesn't. Is there a method to build a fully resolved module? Thanks Mike Klein Manager of System Services Loyola University New Orleans 6363 St. Charles Ave. New Orleans, LA 70118 (504) 865-3470 -- -- 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: [PATCH] buffer overrun in rfc822_8bit()
On Tue, 11 Jan 2005 14:50:23 -0800 (Pacific Standard Time) Mark Crispin [EMAIL PROTECTED] wrote: Thank you. I agree with your suggested patch, and it will be in the next release. Thanks! -- Wbr, Antony Dovgal aka tony2001
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: IMAP over SSL using port 993?
Excellent, you just made my day. Thanks Mark!
Mark Crispin wrote:
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.
unable to lock append mailbox
Hi, i am experiencing with UW imap and the tmail program. My test system is a debian sarge system, I'm using the mbx mailbox format. Sometimes (and I don't see any dependencies) the tmail program writes the error message unable to lock append mailbox. After that, tmail writes the message retrying delivery to INBOX. In some cases the delivery fails and sometimes the new try succeeds. Could anybody tell me, what this error message means and how I can fix this error ? Many thanks Stefan -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
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.
[PATCH] buffer overrun in rfc822_8bit()
Hi all!
Trying to find a cause of http://bugs.php.net/31431 I've discovered
that rfc822_8bit() function (from src/c-client/rfc822.c, line 1938)
incorrectly computes maximum result length.
This causes buffer overrun segfault.
Current formula:
---
unsigned char *ret = (unsigned char *)
fs_get ((size_t) (3*srcl + (6*srcl)/MAXL + 3));1
---
As far as I understand this formula should be written like this:
---
3[encoded char len]*source length
+
((3[encoded char len]*source length)/MAXL[max line length])*3[line ending:
=\r\n])
+
3[=\r\n at the end]
---
So, c-client should use this line instead:
---
unsigned char *ret = (unsigned char *)
fs_get ((size_t) (3*srcl + ((3*srcl)/MAXL)*3 + 3));
---
The patch is attached.
Thanks.
--
Wbr,
Antony Dovgal aka tony2001
--- rfc822.c.orig 2005-01-07 01:53:34.652514640 +0300
+++ rfc822.c2005-01-07 01:53:58.716856304 +0300
@@ -1940,7 +1940,7 @@
{
unsigned long lp = 0;
unsigned char *ret = (unsigned char *)
-fs_get ((size_t) (3*srcl + (6*srcl)/MAXL + 3));
+fs_get ((size_t) (3*srcl + ((3*srcl)/MAXL)*3 + 3));
unsigned char *d = ret;
char *hex = 0123456789ABCDEF;
unsigned char c;
Difficulty compiling IMAP-2004b on Sparc E250 running Solaris 2.8
Hi, I have a Sparc E250 server running Solaris 2.8. I am trying to build IMAP-2004b on this system but I am encountering problems during the compilation. I don't have OpenSSL installed in the default location of /usr/local/ssl. It is a symbolic link to another filesystem. I edited the Makefile in src/osdep/unix to reassign SSLDIR to the proper physical location, /opt/sfw/ssl. I performed a make gso. It seems like the make is stopping on some complaints about some redefinitions and previous declarations in osdep.c. The definitions apparently are from the header files that come with OpenSSL. Can anyone shed some light on this for me? Thanks in advance, -Bill Thomason Here is a copy of the complete build session until it stops on an error: Script started on Thu Jan 06 17:14:53 2005 # pwd /export/home/wbt/IMAP/UW/imap-2004b # make gso make sslnopwd make[1]: Entering directory `/export/home/wbt/IMAP/UW/imap-2004b' + + Building in full compliance with RFC 3501 security + requirements: ++ TLS/SSL encryption is supported ++ Unencrypted plaintext passwords are prohibited + make[1]: Leaving directory `/export/home/wbt/IMAP/UW/imap-2004b' Applying an process to sources... tools/an ln -s src/c-client c-client tools/an ln -s src/ansilib c-client tools/an ln -s src/charset c-client tools/an ln -s src/osdep/unix c-client tools/an ln -s src/mtest mtest tools/an ln -s src/ipopd ipopd tools/an ln -s src/imapd imapd tools/an ln -s src/mailutil mailutil tools/an ln -s src/mlock mlock tools/an ln -s src/dmail dmail tools/an ln -s src/tmail tmail ln -s tools/an . make build EXTRACFLAGS='' EXTRALDFLAGS='' EXTRADRIVERS='mbox' EXTRAAUTHENTICATORS='' PASSWDTYPE=std SSLTYPE=nopwd IP=4 EXTRASPECIALS='' BUILDTYPE=gso make[1]: Entering directory `/export/home/wbt/IMAP/UW/imap-2004b' Building c-client for gso... echo `cat SPECIALS` c-client/SPECIALS cd c-client;make gso EXTRACFLAGS=''\ EXTRALDFLAGS=''\ EXTRADRIVERS='mbox'\ EXTRAAUTHENTICATORS=''\ PASSWDTYPE=std SSLTYPE=nopwd IP=4\ make[2]: Entering directory `/export/home/wbt/IMAP/UW/imap-2004b/c-client' sh -c '(strings /lib/libc.a | grep getpassphrase /dev/null) ln -s os_soln.h os_sol.h || ln -s os_solo.h os_sol.h' make build EXTRACFLAGS='' EXTRALDFLAGS='' EXTRADRIVERS='mbox' EXTRAAUTHENTICATORS='' PASSWDTYPE=std SSLTYPE=nopwd IP=4 `cat SPECIALS` OS=sol \ SIGTYPE=psx CHECKPW=psx CRXTYPE=nfs \ SPOOLDIR=/var/spool MAILSPOOL=/var/mail \ ACTIVEFILE=/usr/share/news/active \ RSHPATH=/usr/bin/rsh \ BASECFLAGS=-g -O2 \ BASELDFLAGS=-lsocket -lnsl -lgen \ RANLIB=true CC=gcc make[3]: Entering directory `/export/home/wbt/IMAP/UW/imap-2004b/c-client' sh -c 'rm -rf auths.c crexcl.c nfstest.c linkage.[ch] siglocal.c osdep*.[ch] *.o ARCHIVE *FLAGS *TYPE c-client.a || true' Once-only environment setup... echo gcc CCTYPE echo -g -O2 '' CFLAGS echo -DCREATEPROTO=unixproto -DEMPTYPROTO=unixproto \ -DMAILSPOOL=\/var/mail\ \ -DANONYMOUSHOME=\/var/mail/anonymous\ \ -DACTIVEFILE=\/usr/share/news/active\ -DNEWSSPOOL=\/var/spool/news\ \ -DRSHPATH=\/usr/bin/rsh\ -DLOCKPGM=\/etc/mlock\ OSCFLAGS echo -lsocket -lnsl -lgen LDFLAGS echo ar rc c-client.a osdep.o mail.o misc.o newsrc.o smanager.o utf8.o siglocal.o dummy.o pseudo.o netmsg.o flstring.o fdstring.o rfc822.o nntp.o smtp.o imap4r1.o pop3.o unix.o mbx.o mmdf.o tenex.o mtx.o news.o phile.o mh.o mx.o;true c-client.a ARCHIVE echo sol OSTYPE ./drivers mbox imap nntp pop3 mh mx mbx tenex mtx mmdf unix news phile dummy ./mkauths md5 pla log make[4]: Entering directory `/export/home/wbt/IMAP/UW/imap-2004b/c-client' echo -DMD5ENABLE=\/etc/cram-md5.pwd\ OSCFLAGS make[4]: Leaving directory `/export/home/wbt/IMAP/UW/imap-2004b/c-client' ln -s os_sol.h osdep.h ln -s os_sol.c osdepbas.c ln -s log_std.c osdeplog.c ln -s sig_psx.c siglocal.c ln -s crx_nfs.c crexcl.c ln -s ip4_unix.c ip_unix.c sh -c '(test -f /usr/include/sys/statvfs.h -a sol != sc5 -a sol != sco) ln -s nfstnew.c nfstest.c || ln -s nfstold.c nfstest.c' Standard password authentication ln -s ckp_psx.c osdepckp.c Building with SSL ln -s ssl_unix.c osdepssl.c echo -I/opt/sfw/ssl/include -I/opt/sfw/ssl/include/openssl -DSSL_CERT_DIRECTORY=\/opt/sfw/ssl/certs\ -DSSL_KEY_DIRECTORY=\/opt/sfw/ssl/certs\ OSCFLAGS echo ssl_onceonlyinit (); linkage.c echo -L/opt/sfw/ssl/lib -lssl -lcrypto LDFLAGS Building with SSL and plaintext passwords disabled unless SSL/TLS echo mail_parameters (NIL,SET_DISABLEPLAINTEXT,(void *) 2); linkage.c cat osdepbas.c osdepckp.c osdeplog.c osdepssl.c osdep.c Building OS-dependent module If you get No such file error messages for files x509.h, ssl.h, pem.h, buffer.h, bio.h, and crypto.h, that means that OpenSSL is not installed on your system. Either install OpenSSL first or build with command: make sol SSLTYPE=none `cat CCTYPE` -c `cat
Re: Crash in mail_setflag_full
Quoting Mark Crispin [EMAIL PROTECTED]: 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. I finally fixed it. The variable containing stream was overwritten by an overflow bug Thanks
Problem sending command
Hi,
I'm trying to send the command for Getannotation and Setannotation (from
ANNOTATE MORE draft)
I must send something like this :
GETANNOTATION INBOX /comment value.priv
I've look at the LIST code and write my code like this :
argument[0].type = ASTRING;
argument[0].text = \INBOX\;
argument[1].type = ASTRING;
argument[1].text = \/comment\;
argument[2].type = ASTRING;
argument[2].text = \value.priv\;
arg[0] = (argument[0]);
arg[1] = (argument[1]);
arg[2] = (argument[2]);
arg[3] = NIL;
reply = imap_send(gStream, SETANNOTATION, arg);
if (imap_OK (gStream,reply)) return NULL;
But instead of creating a single line, I get 3 message :
GETANNOTATION {xxx}
followed by a +go ahead from server
and so on.
The message send for the LIST command is complete
Does anybody has an idea of how format my argument to send a single message?
Thanks
Julien Hamaide
--
--
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/c-client-list.html
--
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
Quoting Mark Crispin [EMAIL PROTECTED]: 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? In my code, either way I would have signaled it :-) Julien
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 --
Crash in mail_setflag_full
Hi, When I call the function this way mail_setflag_full(stream, valid_uid, \\Deleted, ST_UID) the program crash. Am i doing something wrong? The version is imap2004a AFAIK (I use a precompiled lib) Thanks -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
copy folders/subfolders
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. thanks a -- -- 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.
Not getting a BYE when a server disconnect
Does c-client send a BYE to mm_notify() or mm_log() when the server disconnect after x minutes of inactivity? I had Ethereal running and when I saw a FIN from the server, c-client never sent a BYE that the connection has been disconnected. -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Mail transfer progress state
Hello c-client subscribers, Happy coming new year to all of you. Is there any way I can get progress state while sending/receiving messages using c-client library? I would like to show how many bytes has been transfered so far and stuff like that. Is there any available callbacks for that? Thanks. -akmal. -- Best regards, Akmal mailto:[EMAIL PROTECTED] -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Platform SDK SP2 problem
Does anybody have had issues with the new platform SDK SP2? I've recompiled the library with it, and I got 2 errors. The first one is a certificate problem ( saying that my certificate is self-sign) so it won't connect. The second one is a crash (bad memory access in the ip_nt.c ip_nametoaddr function. I'm not sure, maybe it comes from the mix of VS6 and VS.NET, but it doesn't work anymore. Does anybody goes through this? Thanks Julien Hamaide -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
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? You need to give the list some usefule information. Such as debug information, errors popping up. You can also take ethereal and check what's being sent back and forth. Then you can read c-clients documentation to see how to enable verbose output etc. *t -- --- Tomas Pospisek http://sourcepole.com - Linux Open Source Solutions ---
Re: name-space protect symbols
Hi Mark. Thanks for the reply. I've created a bug report with the mysql folks aswell. http://bugs.mysql.com/bug.php?id=7428 I would be inclined it's something better suited for them to fix on their end as earlier versions of mysql 4.1.x worked when being linked with c-client. When I sent this I wanted to ensure i've chased up on both ends. Best Regards- Quoting Mark Crispin [EMAIL PROTECTED]: This message was sent using IMP, the Internet Messaging Program.
Configuration problems
Hi all, 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? Best regards, -Erich- -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
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: Quota Support in UW Imap
On Sun, 19 Dec 2004, Mark Crispin wrote:
On Sun, 19 Dec 2004, Dan Mahoney, System Admin wrote:
I was wondering if UW Imap had the ability to report the system quota of the
mail directory (i.e. the home directory) to users who were using the QUOTA
extension.
At the current time, the answer is no.
I know this is a pretty standard system call (I think)...so it shouldn't be
too difficult to implement.
Unfortunately, this is not the case; there are at least three different
implementations of UNIX quotas that I am aware of, each with different
semantics. It would be fairly easy to assume that all the world is
Linux and implement the QUOTA extension for Linux only; but imapd runs on
many platforms besides Linux.
[snip..]
Finally, IMAP QUOTA isn't defined in terms that directly map to UNIX
quota; the suggested resources are STORAGE and MESSAGE, however on UNIX it
is typically by disk block. There are also independent concepts of
grace space which isn't represented in IMAP QUOTA.
None of this mean that it can't be done; however, to be useful and
correct is quite a bit more complicated than the obvious simple
implementation.
I fully respect Mark's comments opinions (after all, he's the person
who has to deal with complaints about UW Imap not working as expected. ;)
Be that as it may, if you're willing to settle for a gas gauge kind of
implementation (IE a general indication of 'how close to empty' rather
than an exact impementation of the standard) then the Unix quota can be
used for a practical QUOTA system. (Particularly for webmail systems
where the users will probably never be able to get an exact handle on
the mailboxes, they just want a general how close am I kind of metric).
We have found this to be quite useful even if not technically 'correct'.
I hacked UW Imap to add two kinds of QUOTA info.
The first (see code defined by QUOTA_CHECK) regularly checks the
user's quota and sends IMAP ALERT messages if they're over.
It sends the text contained in one of two different files
(see QUOTA_CHECK_WARN_MESS_FILE QUOTA_CHECK_ERROR_MESS_FILE)
via 'palert'.
The second is a quick-and-dirty implementation of the QUOTA extension
(see code defined by DO_QUOTA).
I've attached two files, the first is a patch to imapd.c (based upon
the 2004a version), the second contains the actual system dependent
quota gathering routines. That code is written for a Sys5 type OS
(we use HP-UX) but there are enough comments in it that a good hacker
should be able to adapt it to other platforms.
patch imapd.c, put quota_check.c in src/osdep/unix, add the
defines to the Makefile for imapd, and rebuild.
If you use the QUOTA_CHECK part, you'll have to create two text files
that contain the messages, one 'alert' for going over soft quota
one for hitting hard. suggest keeping the messages to a single line.
Please do not bother Mark about this stuff. I'll try to answer
questions about it but cannot promise anything WRT porting the OS
dependent part to another platform.
Dave
--
Dave Funk University of Iowa
dbfunk (at) engineering.uiowa.eduCollege of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_adminIowa City, IA 52242-1527
#include std_disclaimer.h
Better is not better, 'standard' is better. B{*** imapd.c.origTue Jun 29 16:56:17 2004
--- imapd.c Mon Dec 20 14:59:48 2004
***
*** 17,22
--- 17,26
* The full text of our legal notices is contained in the file called
* CPYRIGHT, included with this Distribution.
*/
+ /*
+ * 2003/12/1 dbfAdd QUOTA capability
+ */
+
/* Parameter files */
***
*** 23,28
--- 27,35
#include stdio.h
#include ctype.h
#include errno.h
+ #ifdef QUOTA_CHECK
+ #include time.h
+ #endif
extern int errno; /* just in case */
#include signal.h
#include time.h
***
*** 43,48
--- 50,64
#define SHUTDOWNTIMER 1 MINUTES /* shutdown dally timer */
#define IDLETIMER 1 MINUTES /* IDLE command poll timer */
#define CHECKTIMER 15 MINUTES /* IDLE command last checkpoint timer */
+ #ifdef QUOTA_CHECK
+ #define QUOTATIMER 30 MINUTES /* quota check timer, how often to check */
+ #ifndef QUOTA_CHECK_WARN_MESS_FILE/* error message to send when over
quota */
+ #define QUOTA_CHECK_WARN_MESS_FILE /etc/imap_quota_alert
+ #endif
+ #ifndef QUOTA_CHECK_ERROR_MESS_FILE
+ #define QUOTA_CHECK_ERROR_MESS_FILE /etc/imap_quota_error
+ #endif
+ #endif/* QUOTA_CHECK */
#define LITSTKLEN 20 /* length of literal stack */
***
*** 124,129
--- 140,151
long crit_set (SEARCHSET **set,unsigned char **arg,unsigned long maxima);
long crit_number (unsigned long *number,unsigned char **arg);
long crit_string (STRINGLIST **string,unsigned char **arg);
+ #ifdef DO_QUOTA
+ int get_quota(char *, char *, int *, int*);
+ #endif
+ #ifdef
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.
Desperate : ipop timeouts
Hi, I have Eudora and Outlook clients that get frequent to occasional connection time outs when checking mail. I believe this is exclusively for the pop users but may be for imap also. We have ~300 users and the ratio of pop to imap is about 15 to 1. The problem we are seeing is that a check for incoming email will occasionally cause a timeout error: Could not connect to mail.magnet.fsu.edu Cause: Connection timed out (10060) Other attempts will be successful, with some timing out. Some users get this a lot, some only a few an hour. I see no relationship to the size of the incoming mailbox and the error. The server load level is low, usually 0.5 to 1.0 and top shows it hardly breaking a sweat. I see no errors in the log files to indicate what the problem is. The server is a dual processor Dell Power Edge 1750 with 2GB of RAM. It is running RHEL 3.0, sendmail 8.13.1 and UW IMAP 2004a. I've played with sittings for xinetd by increasing the number of connections allowed, turning off LIBWRAP and other things but nothing helps. I've also tried increasing the buffer size in the Advanced Network settings for Eudora but this doesn't help either. Do realize that this is an intermittent problem for individual clients. They will get the timeout but then they can turn around and check their email. I was running may email services under Solaris on an Ultra 10 which is not nearly as powerful as the dual Xeon PowerEdge 1750 and never had this problem with the same load. I have done a lot of searching and have not see anyone with this problem. I hope you guys have seen this before and can save my holidays! Thanks! --Tom Combs -- Tom Combs E-mail: [EMAIL PROTECTED] National High Magnetic Field LaboratoryPhone: (850) 644-1657 1800 E. Paul Dirac Drive Tallahassee, FL 32310 -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
