[Imap-uw] Force IMAP server to refresh message flags?
How does the client tell the server to refresh the message flags? The client is multithreaded and that we have multiple connections to the server (2). We have a situation where the client mark a message as read in one thread, but when the synchronize the folder, the client send . UID FETCH 15402 FLAGS, the server send back * 5261 FETCH (FLAGS (\Answered) UID 15402) which mean that the message is unseen for that connection. Obviously the IMAP server is caching the flags for the connection, but I need it to dump the cache or refresh the message cache, but without logging out and log back in every time the client want to get the message flags. Regards, Shawn ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] How to manage c-client memory management?
Joel Reicher wrote: Shawn Walker writes: I would say that Nokia N800 does not store all of you message on your phone. I can access my 15,000 IMAP folder with my iPhone with 16 GB of memory, but the iPhone does not does download all 15,000 messages, just the first 100 or whatever I have it configured it for. Why are you downloading any? http://tools.ietf.org/html/rfc1733 No mailbox data are kept on the client; the client retrieves data from the server as is needed. Did you mean to say caching? Yes, caching and to allow the users to work/read their messages while offline. It's just not messages, but events, tasks, contacts, etc. And for anybody to be able to read their messages from the server, it has to be downloaded unless I'm missing something about how to get the messages from the server to the client. The users that we are dealing with will and always will download all 30,000, 100,000 1,000,000 messages to their computer. We cannot control how the user want to use the p roduct. Unless we really cripple how the product work. When Jon Postel said ...be liberal in what you accept from others he probably did not have this kind of protocol abuse in mind. Force these non-IMAP users to use POP; that's what they're already doing. POP won't give the ability for the users use the IMAP server as the data storage for their messages. I'm not running a server for these users, just providing them a application to be able to groupware functionality of their data on the IMAP server. I also cannot tell users how they managed their data on the server. That's the admin's job that is maintaining those IMAP servers and set quotas to limit how much data the user can have on the server. And there are some admin that doesn't set a quota so the user has unlimited space to store their messages. Cheers, - Joel ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw -- Shawn Walker Senior Software Developer Bynari, Inc. 6220 Gaston Ave, Suite 403 Dallas, Tx 75214 http://www.bynari.net swal...@bynari.net (800) 241-1086 (214) 350-5772 X29 (214) 352-3530 fax ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] How to manage c-client memory management?
Mark Crispin wrote: On Mon, 13 Jul 2009, Shawn Walker wrote: I have an issue that I would like to tell c-client to flush it's cache since I don't want it to keep headers, body of the messages, etc for 20,000 messages since it take up a lot of memory. Either mail_free_cache() or use short caching (OP_SHORTCACHE mode of open). I'm trying OP_SHORTCACHE, but this seems to slow the download messages since now each message has to be fetched from the server. What I would like c-client to do is that it knows there are 30,000 messages in a folder. I request the first 100 messages, either that would be just the envelope or the entire message (depending on the user's configuration). After I have processed those 100 messages, I want c-client to release the memory of those messages. The reason why we have a configuration to allow users to do 'download headers only', 'only download message of the body', 'don't download attachments' and 'only download attachments if they are less than X bytes' is because there are countries that have very low bandwidth (Australia has 180k) and to download huge files can take a long time. mail_free_cache wouldn't be the ideal function to call since that wipe out the list of known messages on the server and cannot download any known messages that I want to download (headers only or just the body of the message or the attachments). I have no idea what you mean by this. I have repeatedly read what you wrote, and I can not make any sense of that combination of words. The issue with calling mail_free_cache is that the nmsgs get reset back to 0 when I'm trying to get the header, envelope, body or attachment as the message is being downloaded or the user took some action that I need to get the text of the message or attachment. Would be ideal that once I have what I wanted downloaded I want c-client to free all of the memory for that message before I go on to the next message. That sounds like short caching, but unless you are running on MS-DOS in 640K, short caching is a very bad idea. UW stopped using short caching about 10 years ago since it is so horribly inefficient. If you want to download without going through caching, you can set up a mailgets function for that purpose. If you just want to download messages to a local copy, why are you using IMAP at all? POP would be better for download. If you want to do interactive access, then you want full caching. The issue is how the users is storing their messages on the server, some users has 30,000, 100,000 or some ridiculous amount of messages in a folder. Caching all of those messages consume the memory. It would be nice if the users would managed their folders better, but we can't be dictating our customers how they should managed their folders. And not everybody has a computer that has 4 GB of memory, some people in eastern Europe is still using computers from the mid nineties running Windows 95! -- Mark -- http://panda.com/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] How to manage c-client memory management?
Mark Crispin wrote: On Tue, 14 Jul 2009, Shawn Walker wrote: I'm trying OP_SHORTCACHE, but this seems to slow the download messages since now each message has to be fetched from the server. Indeed it does. If you want to use early 1990s memory models, you must suffer early 1990s performance problems. there are countries that have very low bandwidth (Australia has 180k) and to download huge files can take a long time. That is why you should cache. Aggressively. Memory is cheaper than bandwidth. There are companies that will not upgrade the computer regardless how cheap memory is today. I can't force the customers to buy more memory. Hence your quote above about 1990s memory models. The issue with calling mail_free_cache is that the nmsgs get reset back to 0 when I'm trying to get the header, envelope, body or attachment as the message is being downloaded or the user took some action that I need to get the text of the message or attachment. I did not see that you were using mail_free_cache(). That is an internal function that you should never call. The appropriate function, which is documented in internal.txt, is mail_gc(). I'll try that out. The issue is how the users is storing their messages on the server, some users has 30,000, 100,000 or some ridiculous amount of messages in a folder. Caching all of those messages consume the memory. Memory is cheaper than bandwidth. I routinely deal with mailboxes of that size. I would not think of slowing things down to save a few pennies of bandwidth. There are companies that will not upgrade the computer regardless how cheap memory is today. I can't force the customers to buy more memory. Hence your quote above about 1990s memory models. And not everybody has a computer that has 4 GB of memory, some people in eastern Europe is still using computers from the mid nineties running Windows 95! 14 year old computers are suitable for tasks of 14 years ago. They are not suitable for modern tasks. At today's netbook prices, there is no excuse to continue using an obsolete, power-wasting, dinosaur. Try saying that to the customers that won't budge on upgrading. We are only forced to have to deal with what the customers are using. Nothing can change that. Try running Outlook on that 100,000 message mailbox on that Windows 95 machine and see how well it does. 4GB of memory costs less than an espresso at Starbucks. However, you should not need anywhere near this. I regularly play with large mailboxes on a Nokia N800 which only has 128MB. I would say that Nokia N800 does not store all of you message on your phone. I can access my 15,000 IMAP folder with my iPhone with 16 GB of memory, but the iPhone does not does download all 15,000 messages, just the first 100 or whatever I have it configured it for. From your use of the word download, you are not using the c-client library effectively. If you were, nobody would ever download 30,000 messages in a session, much less 100,000 messages. The users that we are dealing with will and always will download all 30,000, 100,000 1,000,000 messages to their computer. We cannot control how the user want to use the product. Unless we really cripple how the product work. Look at the Alpine source code for an example of how it is done properly. Using Alpine source to how we need to use IMAP is comparing apples and oranges. If we could control how the application is running then we could model after Alpine. -- Mark -- http://panda.com/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. -- Shawn Walker Senior Software Developer Bynari, Inc. 6220 Gaston Ave, Suite 403 Dallas, Tx 75214 http://www.bynari.net swal...@bynari.net (800) 241-1086 (214) 350-5772 X29 (214) 352-3530 fax ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
[Imap-uw] How to manage c-client memory management?
I have an issue that I would like to tell c-client to flush it's cache since I don't want it to keep headers, body of the messages, etc for 20,000 messages since it take up a lot of memory. mail_free_cache wouldn't be the ideal function to call since that wipe out the list of known messages on the server and cannot download any known messages that I want to download (headers only or just the body of the message or the attachments). Would be ideal that once I have what I wanted downloaded I want c-client to free all of the memory for that message before I go on to the next message. Regards, Shawn ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] Best way to refresh the message numbers of a stale folder?
I never thought you were hiding anything about some secret code to refresh the message cache. Just asking if you have any suggestions to get the message cache updated. I never implied IDLE is push, why I used quotes around push. I understand the logic behind IDLE. What we are doing is giving the users the impression that the messages is being pushed but it's not. IDLE just notify the client something happened, go figure it out. I'll just figure a way to get the message cache update properly. Shawn Mark Crispin wrote: There is no refresh. The concept is meaningless in IMAP, particularly for number of messages and other mailbox state. Mailbox state is always pushed from the server to the client. You need to deal with the underlying cause. If the client state is stalled, then your code is in some way failing to update client state properly. Probably, either your implementation of IDLE is incorrect, or (as suggested in my previous message) you incorrectly expect state to cross from one session to the other without per-session notification. There is nothing that you can do to refresh client state. I understand your desire for a simple palliative. In this case the palliative is neither simple, nor effective, nor existent. I am not hiding some secret technique from you. You can continue searching for such, but will continue to be frustrated until you change course and go about it the right way. Last, but not least, IDLE is not push. In many servers IDLE causes worse battery consumption, and doesn't deliver instantaneous notification for all that (the delay can be up to 1 minute in UW and Panda). If your customers expect push, they will be very disappointed with a product that does IDLE. Apple does not do IDLE on iPhone and iPod Touch at all. RIM does IDLE between BIS and the IMAP server, but does real push (not IDLE or even IMAP at all) to the BlackBerry. Put another way, BIS runs interference and prevents the battery consumption problems caused by IDLE. I am sorry if this free advice is not to your liking. I tell people what they need to know to solve their problem, which is not necessarily they want to hear. On Fri, 13 Mar 2009, Shawn Walker wrote: Mark, c-client as a IMAP client now does support IDLE, multi-threaded (for IDLE and because the Windows application is a multi threaded application) and support asynchronous sessions to be able to handle IDLE. This was done so that the application can use c-client for the IMAP client communication. The code was modified to be able to handle that. I know you are not a fan of IDLE, but our customers wanted the push feature to get e-mails instantaneously instead of the client polling the server X minutes (or seconds if the client want to be aggressive about it). Everything is working great except for one small issue. The client has two IMAP sessions opened in two different threads (in a single process, multi-threaded). The reason is out of my control due to how the windows application was written (but that's another discussion for another day). From the process IDLE thread, the client got the untagged IMAP responses, the client end the IDLE with the DONE command and then the client sent a NOOP, but the message cache is still staled. I'm not here to debate what is wrong in your view with using IDLE, multi-threaded application, using more than one IMAP connections to the IMAP server. I just want a solution to how to get c-client to refresh it's message cache properly without having to disconnect and reconnect to the server. Regards, Shawn Mark Crispin wrote: On Fri, 13 Mar 2009, Shawn Walker wrote: The application has multiple threads with 2 connections to the IMAP server. One of them is for IDLE. This application does not use c-client to do IMAP client. c-client does not support client-end IDLE. Presumably, by thread, you mean threads in a process as opposed to message threads. UW imapd does not run multi-threaded; each IMAP session has its own process. Nor does the c-client library use threads. So, whatever is threading and using IDLE does not seem to have anything to do with c-client or imapd. When something happen on the IDLE thread, the server send a list of untagged IMAP commands to the client of what happened. The server sends untagged IMAP responses, not commands. The IDLE thread see that it need to update a folder, but the IDLE thread has two messages the UID of 100 and 101 (an example). But, UID 101 is doesn't exist anymore, but UID 102 is on the server. So, the IDLE thread request the message cache for UID 102 but c-client doesn't know about 102 in it's message cache due that it only know of UID 100 and 101 and return with a NIL. Hence, the message cache is stale. This makes no sense, so I have to guess what you are talking about. My guess is that client has two IMAP sessions open. One of those sessions did an IDLE command that notified
[Imap-uw] Best way to refresh the message numbers of a stale folder?
What is the best way to refresh a stale folder state? I'm having a issue with one thread that contain a stale UID in it's cache. I know that I could disconnect from the server and reconnect, but is rather expensive to have to wait for the server/client to connect. Regards, Shawn ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
[Imap-uw] Optimize way to retreive UIDs?
I have a situation that I need to get a list of UIDs in a range but I have no idea how many UIDs is in that range. I can't just request all of the UIDs in a range since there might be thousands of UIDs and I can't give the impression that the application isn't doing anything while I wait for the UIDs to be retrieved. What I'm looking for is that I can give a starting UID and say I want 25 UIDs. Then I can keep calling that until I know that I have all of the UID based on the number of messages in the IMAP folder. Is there such a thing? I know you give a UID range, as in UID:UID-25 and that might give you up to 25 UIDs or 0, but all I know is that the NEXTUID is a very large value and it's time consuming to have to keep calling the server for every UID that doesn't exist. I'm currently calling mail_search_full to get the list of UIDs, either 1:NEXTUID or LASTUID:NEXTUID, so obviously, 1:NEXTUID can be very time consuming depending on how many messages is in the folder. Regards, Shawn ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] Quotas tmail
Mark Crispin wrote: Actually those settings seem to be part of the experimental things under the Labs settings tab. You have to enable it there to have it show up at all, but there are a lot of warnings and disclaimers about doing so. I don't see any Labs setting tab. I assumed that he misspelled Labels. Apparently Google does not consider me to be privileged to see their experimental features. Somehow, this does not surprise me. There is a Labs tab under settings. I see it in my gmail settings. ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] utf8_mime2text doesn't decode ISO-8859-1''%...
Mark Crispin wrote: Are you back to maintain c-client? I maintain c-client for my own purposes, but I am no longer in the business of developing or maintaining it for others. But, after digging around the code, I found out a previous developer never finished the code to decode rfc2047. I have just completed the coding and now the filename is decoded correctly. I am the only developer that c-client has ever had, and I do not have a clue as to what you are talking about. RFC 2047 is implemented. The tokens that you are having problems with are RFC 2031. I meant RFC 2031 wasn't completed, sorry for the confusion. _ Your PC, mobile phone, and online services work together like never before. http://clk.atdmt.com/MRT/go/108587394/direct/01/ -- Shawn Walker Senior Software Developer Bynari, Inc. 6220 Gaston Ave, Suite 403 Dallas, Tx 75214 http://www.bynari.net [EMAIL PROTECTED] (800) 241-1086 (214) 350-5772 X29 (214) 352-3530 fax ___ Imap-uw mailing list Imap-uw@u.washington.edu http://mailman2.u.washington.edu/mailman/listinfo/imap-uw
[Imap-uw] DecryptMessage failing on Vista
I'm having an issue with DecryptMessage failing on Vista with SEC_E_DECRYPT_FAILURE. Running on Windows XP doesn't have any issues using SSL. Is anybody having issues with SSL DecryptMessage on Vista? I have attached a network trace to see if it helps on what is going on. Regards, Shawn No. TimeSourceDestination Protocol Info 373 82.295769 192.168.3.254 xx.xx.xxx.xx TCP 49217 993 [SYN] Seq=0 Len=0 MSS=1460 WS=8 Frame 373 (66 bytes on wire, 66 bytes captured) Ethernet II, Src: Vmware_6c:72:b2 (00:0c:29:6c:72:b2), Dst: 3com_30:ab:f1(51:b3:02:30:ab:f1) Internet Protocol, Src: 192.168.3.254 (192.168.3.254), Dst: xx.xx.xxx.xx (xx.xx.xxx.xx) Transmission Control Protocol, Src Port: 49217 (49217), Dst Port: 993 (993), Seq: 0, Len: 0 No. TimeSourceDestination Protocol Info 375 83.200106 xx.xx.xxx.xx 192.168.3.254 TCP 993 49217 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=0 Frame 375 (66 bytes on wire, 66 bytes captured) Ethernet II, Src: 3com_30:ab:f1(51:b3:02:30:ab:f1), Dst: Vmware_6c:72:b2 (00:0c:29:6c:72:b2) Internet Protocol, Src: xx.xx.xxx.xx (xx.xx.xxx.xx), Dst: 192.168.3.254 (192.168.3.254) Transmission Control Protocol, Src Port: 993 (993), Dst Port: 49217 (49217), Seq: 0, Ack: 1, Len: 0 No. TimeSourceDestination Protocol Info 376 83.200401 192.168.3.254 xx.xx.xxx.xx TCP 49217 993 [ACK] Seq=1 Ack=1 Win=65536 Len=0 Frame 376 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: Vmware_6c:72:b2 (00:0c:29:6c:72:b2), Dst: 3com_30:ab:f1(51:b3:02:30:ab:f1) Internet Protocol, Src: 192.168.3.254 (192.168.3.254), Dst: xx.xx.xxx.xx (xx.xx.xxx.xx) Transmission Control Protocol, Src Port: 49217 (49217), Dst Port: 993 (993), Seq: 1, Ack: 1, Len: 0 No. TimeSourceDestination Protocol Info 385 85.545468 192.168.3.254 xx.xx.xxx.xx TLSv1Client Hello Frame 385 (180 bytes on wire, 180 bytes captured) Ethernet II, Src: Vmware_6c:72:b2 (00:0c:29:6c:72:b2), Dst: 3com_30:ab:f1(51:b3:02:30:ab:f1) Internet Protocol, Src: 192.168.3.254 (192.168.3.254), Dst: xx.xx.xxx.xx (xx.xx.xxx.xx) Transmission Control Protocol, Src Port: 49217 (49217), Dst Port: 993 (993), Seq: 1, Ack: 1, Len: 126 Secure Socket Layer No. TimeSourceDestination Protocol Info 386 85.583699 192.168.30.31 192.168.30.255UDP Source port: 32769 Destination port: 694 Frame 386 (205 bytes on wire, 205 bytes captured) Ethernet II, Src: Intel_e3:29:af (00:90:27:e3:29:af), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Internet Protocol, Src: 192.168.30.31 (192.168.30.31), Dst: 192.168.30.255 (192.168.30.255) User Datagram Protocol, Src Port: 32769 (32769), Dst Port: 694 (694) Data (163 bytes) 3e 3e 3e 0a 74 3d 73 74 61 74 75 73 0a 73 74 3d .t=status.st= 0010 61 63 74 69 76 65 0a 73 72 63 3d 6d 61 69 6c 32 active.src=x 0020 2e 65 78 61 6d 70 6c 65 2e 6e 65 74 0a 73 65 71 .xxx.xxx.seq 0030 3d 33 30 64 62 62 39 0a 68 67 3d 32 30 0a 74 73 =30dbb9.hg=20.ts 0040 3d 34 37 34 63 37 35 64 32 0a 6c 64 3d 30 2e 30 =474c75d2.ld=0.0 0050 30 20 30 2e 30 30 20 30 2e 30 30 20 31 2f 31 34 0 0.00 0.00 1/14 0060 36 20 31 37 35 38 34 0a 74 74 6c 3d 33 0a 61 75 6 17584.ttl=3.au 0070 74 68 3d 31 20 30 34 30 33 32 36 32 36 36 34 37 th=1 04012636647 0080 62 65 66 62 61 35 66 34 31 33 34 63 66 62 37 33 befbdbf4a218fb73 0090 62 65 66 35 62 33 65 35 64 35 65 64 61 0a 3c 3c bff5f3bee5eda. 00a0 3c 0a 00 .. No. TimeSourceDestination Protocol Info 387 85.593833 xx.xx.xxx.xx 192.168.3.254 TLSv1Server Hello, Certificate, Server Hello Done Frame 387 (1008 bytes on wire, 1008 bytes captured) Ethernet II, Src: 3com_30:ab:f1(51:b3:02:30:ab:f1), Dst: Vmware_6c:72:b2 (00:0c:29:6c:72:b2) Internet Protocol, Src: xx.xx.xxx.xx (xx.xx.xxx.xx), Dst: 192.168.3.254 (192.168.3.254) Transmission Control Protocol, Src Port: 993 (993), Dst Port: 49217 (49217), Seq: 1, Ack: 127, Len: 954 Secure Socket Layer No. TimeSourceDestination Protocol Info 388 85.599710 192.168.3.254 xx.xx.xxx.xx TLSv1Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message Frame 388 (252 bytes on wire, 252 bytes captured) Ethernet II, Src: Vmware_6c:72:b2 (00:0c:29:6c:72:b2), Dst: 3com_30:ab:f1(51:b3:02:30:ab:f1) Internet Protocol, Src: 192.168.3.254 (192.168.3.254), Dst: xx.xx.xxx.xx (xx.xx.xxx.xx) Transmission Control Protocol, Src Port: 49217 (49217), Dst Port: 993 (993), Seq: 127, Ack: 955, Len: 198 Secure Socket Layer No. TimeSourceDestination Protocol Info 389 85.701984 xx.xx.xxx.xx 192.168.3.254
Re: [Imap-uw] Annotation support for the c-client library
FYI, ANNOTATEMORE has been depreciated, the name is now METADATA. But, to support existing clients out there, the code should look for ANNOTATEMORE and METADATA. http://ietfreport.isoc.org/idref/draft-daboo-imap-annotatemore/ Shawn Mark Crispin wrote: Thanks for contacting me about your interest in the ANNOTATEMORE patch. I have had a copy of it in my queue since 2005; and I have been waiting to see the final disposition of the ANNOTATEMORE specification (which is still a draft, not an RFC). In particular, newer drafts use the standard astring rule as opposed to quoted strings, which would eliminate the need for the QSTRING/QLIST code in the patch (which I really do not want to use if possible). I'll contact the author of the specification and inquire about its status. Also, I'm considering support for annotations in the new mix format; and thus wanted to review the interface in the patch to be sure that it would be more generally suitable as well. Last but not least, I've been mulling over a possiblity of creating an interface by which you could plug in support for new IMAP extensions without having to modify c-client itself. In other words, Kolab could support ANNOTATEMORE itself using the unmodified c-client interface. This hasn't gone beyond the thinking about stage yet, but this might end up being the best overall solution. Thanks for reminding me that I need to do something about this eventually. -- Mark -- http://staff.washington.edu/mrc Science does not emerge from voting, party politics, or public debate. Si vis pacem, para bellum. ___ Imap-uw mailing list Imap-uw@u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw ___ Imap-uw mailing list Imap-uw@u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] Invalid UID
Mark Crispin wrote: This test is unnecessary. mail_newsearchpgm() never returns null; the application will crash if the malloc() fails. Why for the life of me is I cannot understand your library calls abort() to crash the application because of out of memory or encounter an error from the server. That is a big no no, please change your library to return a failure and have the application that is calling your library to deal with errors. If the applications refuses to check for errors, then that is their problem. ___ Imap-uw mailing list Imap-uw@u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
Re: [Imap-uw] How to force c-client to redownload message
I know for a fact the IMAP connection never broke. I have the network trace that shows the connection is fine (you can look at it if you want to). c-client is returning a NULL BODY structure and I can never go download the message's bodies. And thus, I want to force c-client to go get the body structure again. Mark Crispin wrote: If c-client has cached a blank body, that means that either the body is blank or that the IMAP connection is broken thus the stream is dead. In the case of the former, redownloading would do no good. In the case of the latter, the recovery procedure is to close the MAILSTREAM and re-open it. There is no retry in IMAP. IMAP is a stateful stream oriented protocol. The notion of retry is only meaningful in stateless datagram oriented protocols such as NFS. On Thu, 8 Jun 2006, Shawn Walker wrote: How do I get c-client to force it to redownload the body structure that c-client caches? I tried calling mail_fetch_structure() again, but nothing. I'm having a issue that c-client is giving me a blank body but the body is there and which causes us to display a empty message to the user. -- Mark -- http://panda.com/mrc Democracy is two wolves and a sheep deciding what to eat for lunch. Liberty is a well-armed sheep contesting the vote. ___ Imap-uw mailing list Imap-uw@u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
[Imap-uw] What is the part number???
I have a message that seems confused from c-client. I have tried it
with Pine 4.64 and it shows the message blank (empty).
I have provided the detail information below. What we are doing is that
we don't download the entire message. We fetch the body structure and
then we retrieve the body of the message later using the part number.
According to the body struture, the TEXT PLAIN is part 1 and
INLINE is part 2. But, c-client is returning the data reversed (from
what I can gather).
How do I determine the correct part number when I need to get the message?
I use mail_fetch_overview_sequence() to get the BODYSTRUCTURE:
BODYSTRUCTURE ((TEXT PLAIN (CHARSET us-ascii) NIL NIL 7BIT 0 0
NIL NIL NIL) MIXED (BOUNDARY 090003040805030408020409)
(INLINE (FILENAME [Fwd: Re: a message])) NIL) BODY[HEADER.FIELDS
(Newsgroups Content-Disposition Content-Language Content-Location
X-Priority Received)] {3884}
The actual raw email looks similar to this:
Received: from [1.2.3.4] (example.net [1.2.3.4])
by example.net (Postfix) with ESMTP id 91C902A593
for [EMAIL PROTECTED]; Fri, 28 Oct 2005 19:39:43 +0200 (CEST)
Message-ID: [EMAIL PROTECTED]
Date: Fri, 28 Oct 2005 20:33:27 +0200
From: User Example [EMAIL PROTECTED]
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050715)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [EMAIL PROTECTED]
Subject: [Fwd: Re: a message]
Content-Type: multipart/mixed;
boundary=090003040805030408020409
This is a multi-part message in MIME format.
--090003040805030408020409
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
--
User Example
--090003040805030408020409
Content-Type: message/rfc822;
name=Re: a message
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename=Re: a message
Return-Path: [EMAIL PROTECTED]
Received: from example.net ([unix socket])
by example (Cyrus v2.2.10) with LMTPA;
Fri, 28 Oct 2005 17:57:13 +0200
X-Sieve: CMU Sieve 2.2
Reply-To: Some User [EMAIL PROTECTED]
Date: Fri, 28 Oct 2005 11:50:37 -0500
Content-Type: text/plain; charset=UTF-8; format=flowed
MIME-Version: 1.0
From: Some User [EMAIL PROTECTED]
Subject: RE: a message
To: Some User [EMAIL PROTECTED]
Message-Id: [EMAIL PROTECTED]
A sample message
--090003040805030408020409--
___
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
[Imap-uw] utf8_mime2text doesn't decode QP correctly?
We have a from address that has: From: =?UTF-8?Q? Fr=C3=A9d=C3=A9ric ?= [EMAIL PROTECTED] utf8_mime2text() can't decode that, if there is no spaces in the encoding such as From: =?UTF-8?Q?Fr=C3=A9d=C3=A9ric?= [EMAIL PROTECTED] utf8_mime2text() decodes it just fine. We are using 2004 of c-client. ___ Imap-uw mailing list Imap-uw@u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
