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 ---
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: using mtest to understand c-client
On Mon, 6 Dec 2004, Andrew Biggs wrote: I'm just getting started using c-client, and was trying to use mtest to talk to an IMAP server on another box. Looking at the code, it's not real clear to me how to specify the remote address, username, password, etc. I didn't see any readme's, FAQ's, or howto's specifically related to this. I have been looking at the API guide for c-client, which is good, but I haven't seen where it covers login. Any suggestions, or pointers to docs I could look at? You can go to mailsync.sf.net, click through to the sourceforge interface, there to the webcvs and look into the examples directory. The c-client docu gives you the precise syntax. *t -- --- Tomas Pospisek http://sourcepole.com - Linux Open Source Solutions ---
Re: reopening a stream with OP_HALFOPEN
On Wed, 1 Dec 2004, Mark Crispin wrote:
On Wed, 1 Dec 2004, Tomas Pospisek's Mailing Lists wrote:
... but - are you saying that I don't even need to change into HALFOPEN
mode in order to be able to append messages to any kind of mailbox without
the Status: O flag being set? That I just have to keep the stream in
READONLY mode?
Stream readonly status refers to operations on the opened mailbox (the
selected mailbox in IMAP terms); it affects such operations as
setting/clearing flags and expunging. It does not in any way affect
operations that work on a mailbox by name, such as append.
So I think that the answer to your question (if I understand it correctly) is
yes.
Hmm - this is starting to be interesting for me. So this means that I
could switch from mailbox to mailbox by opening them READONLY and that
this would not issue internally an open/close on the stream and thus not
require a re-authentication?
So in the general case, that is for local and remote mailboxes of a random
format supported by c-client I can:
foreach mailbox in mailboxes_at_a_location {
stream = open(mailbox, READONLY); # first step (read)
read_mails(stream)#
stream = open(mailbox, READWRITE);# second step (expunge)
flag_removed_mails(stream); #
expunge(stream); #
stream = open(mailbox, READONLY); # third step
append(new_mails, mailbox-name); #
}
Q1: If I ommit the second step, then I can guarantee that all email stati
are maintained, especially Status: O will not be set by c-client or
the IMAP server no matter what format the mailbox is in. Correct?
Q2: It would be interesting if there exists a way to delete emails in a
mailbox (that is the second step) without affecting the Status:
respectively the flags of any other email in that mailbox or any other
mailbox (this again for the general case).
Q3: Or if there is a way to remove Status: O after the fact
(afterwards). As I understand though this is not possible for the
general case. Correct?
If any of the two (preferable the later method - removing Status: O)
could be achieved, then mailsync could be implemented in a perfect
way.
Thanks,
*t
--
---
Tomas Pospisek
http://sourcepole.com - Linux Open Source Solutions
---
reopening a stream with OP_HALFOPEN
I've got reports [1] against Debian's version of c-client 2002e that when opening a stream, that is not OP_HALFOPEN (such as OP_READONLY or NIL), c-client will actually close and open the stream again (thus requiring the user to re-authenticate). Is this: * a known problem? * a feature with a rationale? * fixed in c-client 2004? Any other comment? *t [1] http://bugs.debian.org/257418 -- --- Tomas Pospisek http://sourcepole.com - Linux Open Source Solutions --- -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Re: reopening a stream with OP_HALFOPEN
On Wed, 1 Dec 2004, Mark Crispin wrote: On Wed, 1 Dec 2004, Tomas Pospisek's Mailing Lists wrote: I've got reports [1] against Debian's version of c-client 2002e that when opening a stream, that is not OP_HALFOPEN (such as OP_READONLY or NIL), c-client will actually close and open the stream again (thus requiring the user to re-authenticate). I assume that you're talking about recycling an already-open stream? Yes. A close and open will happen if c-client determines that the new mailbox name is not compatible with the existing stream. If you recycle a non-halfopen stream, and decide that you want the stream to be halfopen now, a close/open is required unless the server supports the UNSELECT capability. That's the only reliable way to get a halfopen session if the server does not have UNSELECT. If you don't care if the stream is halfopen or not, then you probably should not call mail_open() with the OP_HALFOPEN flag to recycle the stream. I'm looking at messages in readonly mode in order to determine which ones need to be synchronized between two sites. Then I'm flagging those as deleted that have been removed on one side. After that I'm appending new messages to mailboxes at both sides. In order to do this without having the Status: O set by c-client I need to change down into OP_HALFOPEN mode. Thanks for the answer! *t -- --- Tomas Pospisek http://sourcepole.com - Linux Open Source Solutions ---
Re: mh not keeping flags intact when doing a check
On Thu, 10 Jun 2004, Mark Crispin wrote: On Thu, 10 Jun 2004, Tomas Pospisek's Mailing Lists wrote: But I don't understand what would be required to fix it. I can't see the big picture. AFAI can see mh_ping is not changing the status of messages. mh format does not have any place to store flags permanently. Flags are only maintained for a session, after which they are lost. The problem I'm fighting against here is that when reopening a connection the c-client's mh driver will loose knowledge of which messages were removed. And wrt *that* flag, my sources seem to be clear - a removed message is prepended with a ',' or with a '#' [1] (that's what one of the mh users is seeing in RL as well). IMHO c-client should do just that: rename all the removed messages, but ... But even if it doesn't, then it should remove - however that should be done - removed messages at mh_check instead of forgeting about the fact they were removed. ? *t [1] http://www.ics.uci.edu/~mh/book/mh/rem.htm -- --- Tomas Pospisek http://sourcepole.com - Linux Open Source Solutions ---
Re: mh not keeping flags intact when doing a check
On Fri, 11 Jun 2004, Mark Crispin wrote: On Fri, 11 Jun 2004, Tomas Pospisek's Mailing Lists wrote: The problem I'm fighting against here is that when reopening a connection the c-client's mh driver will loose knowledge of which messages were removed. That problem is insurmountable. If it is a problem for you, the solution is simple: do not use mh format. Let me see what my users will answer me. And wrt *that* flag, my sources seem to be clear - a removed message is prepended with a ',' or with a '#' [1] (that's what one of the mh users is seeing in RL as well). Like POP style deletion, what mh calls deletion seems similar to IMAP deletion (and c-client implements strict IMAP semantics). That similarity is deceptive. Once you do a careful study of how mh actually works and what IMAP requires, it becomes clear that it is impossible to implement the IMAP semantics of deletion using mh deletion. There is a difference between working some of the time and working all the time; and it is not an option to deviate from strict compliance with IMAP requirements. If it was possible to do it, I would have done it 12 years ago. The solution is not to use mh format. So it's better to leave the mh driver broken and very hard to use in a useful way, because it would not be possible to make it strictly IMAP semantics compliant (presonally it's still not clear why). *Is* the mh driver strictly IMAP semantics compiant right now? Is the fact that a) it forgets about all the flags and b) when reusing an open connection it just forgets about all the deleted messages strictly IMAP semantics compliant? Would it make the situation worse to fix that behaveour? *t -- --- Tomas Pospisek http://sourcepole.com - Linux Open Source Solutions ---
Re: open_mail, flags and synchronization
Since Mark seems to be listening on the list, but there's no reply yet: let's make the requirements a bit lighter and ask some more specific questions. I'll cut this email in two, since it is two different questions actually. On Wed, 9 Jun 2004, Tomas Pospisek's Mailing Lists wrote: I'm trying to fix mailsync a mail synchronizer to properly work wrt to flags. I'm trying to accomplish this by using c-client. I need to: * read the headers in box A * read the headers in box B * determine from the header which emails I have already seen in what inbox (same algorithm CVS is using) * copy all messages that A hasn't seen from B to A * copy all messages that B hasn't seen from A to B * delete all messages on B that were deleted on A * delete all messages on A that were deleted on B * expunge A * expunge B Now the mailsync source code is juggling with mail_open in a rather ugly way and I am not sure whether it is really succeeding in all cases to keep all the flags (especially seen) intact on both A and B and at the same time trying to do that transparently with respect to where those boxes are (IMAP, mbox, mh, remote, locally, ...). So my first question is: is there a way to achieve the above with c-client, that is guaranteed to work? Basically this means: * open a box for reading messages * open a box for appending messages * expunge a box and at the same time keep all flags as they were. Expunging a box will, AFAIK traverse all messages, look for those that are marked for deletion and remove them. A side effect of this seems to be, that all those traversed messages seem to get marked as Seen aka Status: O (old). Is this a requirement of some sort? Isn't there a way around it? So if there isn't - can we fullfull our requirements, that is to leave all flags alone, even the Seen one, if we don't expunge? Or can't that be guaranteed even then? *t -- --- Tomas Pospisek http://sourcepole.com - Linux Open Source Solutions ---
mh not keeping flags intact when doing a check
On Wed, 9 Jun 2004, Tomas Pospisek's Mailing Lists wrote:
Second question:
some of my MH users say that re-mail_open'ing a MH store will make it
forget all all removal flags.
Is this a known bug/problem/feature. Is there a work around or should I
try to fix c-clients source with respect to this?
osdep/unix/mh.c says:
void mh_check (MAILSTREAM *stream)
{
/* Perhaps in the future this will preserve flags */
if (mh_ping (stream)) mm_log (Check completed,(long) NIL);
}
So I guess the problem is known.
But I don't understand what would be required to fix it. I can't see
the big picture. AFAI can see mh_ping is not changing the status of
messages.
So do you flag messages in memory or something similar when marking them
for deletion? And so a mh_ping doesn't take in memory structures in
account and only checks on disk messages and by this invalidates in
memory information? But even then - I don't see mh_ping flushing any in
memory data? So where do those flags get lost?
*t
--
---
Tomas Pospisek
http://sourcepole.com - Linux Open Source Solutions
---
--
--
For information about this mailing list, and its archives, see:
http://www.washington.edu/imap/c-client-list.html
--
open_mail, flags and synchronization
I'm trying to fix mailsync a mail synchronizer to properly work wrt to flags. I'm trying to accomplish this by using c-client. I need to: * read the headers in box A * read the headers in box B * determine from the header which emails I have already seen in what inbox (same algorithm CVS is using) * copy all messages that A hasn't seen from B to A * copy all messages that B hasn't seen from A to B * delete all messages on B that were deleted on A * delete all messages on A that were deleted on B * expunge A * expunge B Now the mailsync source code is juggling with mail_open in a rather ugly way and I am not sure whether it is really succeeding in all cases to keep all the flags (especially seen) intact on both A and B and at the same time trying to do that transparently with respect to where those boxes are (IMAP, mbox, mh, remote, locally, ...). So my first question is: is there a way to achieve the above with c-client, that is guaranteed to work? Basically this means: * open a box for reading messages * open a box for appending messages * expunge a box and at the same time keep all flags as they were. Second question: some of my MH users say that re-mail_open'ing a MH store will make it forget all all removal flags. Is this a known bug/problem/feature. Is there a work around or should I try to fix c-clients source with respect to this? Thanks a lot, *t -- --- Tomas Pospisek http://sourcepole.com - Linux Open Source Solutions --- -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
Re: Anyone with MH patches?
On Wed, 10 Dec 2003, Erik Berls wrote: I've looked through the mail archives and I've seen support issues for MH folders come up numerous times. I was wondering if anyone had patches that implemented the ability to maintain the read/un-read status of messages. Ideally, I would prefer if this was done via updating the .mh_sequences file, however I'm willing to take any support along this line. (Alternately, if people out there view this as working, please tell me what I need to do to kick Mail.app 1.3 [OS X, Panther] into functioning proper.) I don't know if Michael hacker Krelin is reading this list, but he's also an avid MH user. Maybe you want to shortcut yourself with him - I'm Cc: ing him this message. *t -- --- Tomas Pospisek http://sourcepole.com - Linux Open Source Solutions ---
Re: imap: How to avoid folder creation?
On Wed, 26 Feb 2003, Friedrich Lobenstock wrote: If the users can only have their INBOX on imap but not any other folders what do they gain from this change. They can move mails back and forth to and from the server, which is impossible with pop. *t -- --- Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11 ---
Re: imap: How to avoid folder creation?
On Thu, 27 Feb 2003, Friedrich Lobenstock wrote: Tomas Pospisek's Mailing Lists wrote: On Wed, 26 Feb 2003, Friedrich Lobenstock wrote: If the users can only have their INBOX on imap but not any other folders what do they gain from this change. They can move mails back and forth to and from the server, which is impossible with pop. What's the point if they can only upload mails to their inbox but not create other folders as that's what the orginal poster wants. IMO better stay with POP3, that's less confusion for the users and change to IMAP when the server got more harddisk space to be able to hold all user folders. You can f.ex synchronize your folders between various workstations. Which you can't with POP. *t -- --- Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11 ---
Status: O
I'm trying to sync mail from an IMAP server to a /var/spool/mail/mbox [1]. The problem is, that mail_append[_full] will allways add a Status: O to the mail, even if I pass an empty string to the function as flags. The problem with this is that the mutt MUA interprets Status: O as an old message, that is != New message, which means that I'm unable to sync with an IMAP server in a way that will enable mutt to see new messages. I think mutt's behaveour is in accordance with RFC2076 which states that: Omessage is old but not deleted. That RFC also states that: Nnew (a new message also sometimes is distinguished by not having any Status: header. If I could achieve either of: * append a message with Status: without any flags * append a message without a Status: header at all * append a message with the flag N as in Status: N then I'd be done, but it doesn't seem that c-client can do any of those (?). If there is a way to achieve that I'd be glad if I could be pointed to the relevant source/docu. Otherwise I'd like to know if such functionality could be added to c-client? *t [1] mailsync.sf.net -- --- Tomas Pospisek SourcePole - Linux Open Source Solutions http://sourcepole.ch Elestastrasse 18, 7310 Bad Ragaz, Switzerland Tel: +41 (81) 330 77 11 --- -- -- For information about this mailing list, and its archives, see: http://www.washington.edu/imap/c-client-list.html --
