hi, i've been searching for a case like this, but i haven't found nothing, so here it goes:
I've moved from a mbox scheme to maildir, for performance reasons. I have: Solaris 9, sendmail (MTA) 11.9.0 configured with "Mlocal, P=/usr/bin/procmail ... A=procmail -Y -a $h -d $u", procmail 3.22, courier-imap 3.0.8 (i previously had 2.2.1, with the same behaviour), and we're using a Maildir structure in user's homes, with a simple (?) ~/.procmailrc listed below. (no global /etc/procmailrc) (I used mbox2maildir.pl for mbox to maildir initial conversion).
The problem : The mail seems to arrive correctly (sendmail+procmail ?), and is stored in Maildir/new. The pop client connects, retrieves messages, and as it usually have the option "don't leave messages on server", delete all message that remains in server... But in fact, the client has not retrieve *all* the messages *always*: there are (not reproducible, afaik) cases in which some message was not downloaded to the client, but was erased from server: we can see it by activating "leave messages on server", and connecting later via an IMAP reader (squirrelmail): some message/s remains unreaded, but the client doesn't know of them anymore... I've seen that these files are listed in Maildir/cur (when "leave messages on server"), and listed in Maildir/courierimapuiddb UIDL's (is this its use?), so i can't explain this random behaviour... Activating logs (without the ultimate level that shows even passwords: the level just before) we can't see any strange thing, but for the amount of retrieved bytes on each transaction, it seems that the "erroneously deleted" messages never leave the server. It all seems a (random) failure of comunication between pop3d and the pop client... ??? btw, it has happened with outlook, netscape messenger, kmail ... so all points to pop3d... ??? Has anybody seen something like this? Does my explanation to the problem make any sense? Is there any patch, action to take, way to get deeper, or anything that can solve this? As u can imagine such a behaviour can't be maintained...
Any help/hint will be appreciated. And i mean *any*!!! thanx
# Please check if all the paths in PATH are reachable, remove the ones that # are not.
PATH=/usr/bin:/usr/ucb:/bin:/usr/local/bin:. MAILDIR=$HOME/Maildir # You'd better make sure it exists DEFAULT=$MAILDIR/new LOGFILE=$MAILDIR/from LOCKFILE=$HOME/.lockmail
# Anything that has not been delivered by now will go to $DEFAULT # using LOCKFILE=$DEFAULT$LOCKEXT
More infos about the problem:
> I've gone deeper into the problem:
> IMAP access seems correct.
> POP3 clients seems to be informed with bad/duplicated UIDs (via POP3
> UIDL ?) or recieved duplicated messages with different UID (which r
> silently discarded by the pop client).
> It seems that there's a problem with access to, or recreation, of files
> related with pop... I suspect of "courierimapuiddb" and/or
> "courierpop3dsizelist"... they seem to be unsynchronized.
> I've even seen a case in which two different messages where mapped in
> "Maildir/from" log file with the same name (which is impossible, of
> course)... when I went to see what happened there, one of the messages
> were named with a temporary name (1001687*.P*N*..._hostname*) and the
> other with its correct name. Mapping of these files to courier*uiddb
> seems to have been incorrect, since one of them weren't delivered to the
> pop client, (and even has changed at least once).
> It all seems to point to a problem of locking/access/file data recreation...
> I've read of this kind of problems with "Maildir/courier*" files... are
> they still unresolved?
> Is there any know problem running my configuration in Solaris 9? (Data
> is stored in an external array, but it should be unreleated).
>
> any hint is appreciated.
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. http://productguide.itmanagersjournal.com/
_______________________________________________
courier-users mailing list
[EMAIL PROTECTED]
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
