Hi,
I lose some imap flags that I put on delivery by setting the KEYWORDS
environment variable in a maildrop recipe.  I tried to dump the
dialog between imaplogin and thunderbird, but couldn't grasp what
happens:

There are several sequences where each folder is queried without
showing the flags, like so:
READ: NUMBER: 918
READ: ATOM: STATUS
READ: QUOTED_STRING: INBOX.Assodom
READ: LPAREN
READ: ATOM: UIDNEXT
READ: ATOM: MESSAGES
READ: ATOM: UNSEEN
READ: ATOM: RECENT
READ: RPAREN
READ: EOL
WRITE: * STATUS "INBOX.Assodom" (MESSAGES 1086 RECENT 1 UIDNEXT 4360 UNSEEN 1)
918 OK STATUS Completed.

Here "INBOX.Assodom" is a folder where the keyword "nopass" should be
set for almost every message.  Instead, it survives in a minority of
them only.  In this case, UID 4359 should have had KEYWORDS="nopass",
as that gets showed by manually running maildrop -V 7 on the same
message.

After a while:
READ: NUMBER: 1119
READ: ATOM: IDLE
READ: EOL
WRITE: + entering ENHANCED idle mode
READ: ATOM: DONE
WRITE: 1119 OK IDLE completed

READ: NUMBER: 1120
READ: ATOM: SELECT
READ: QUOTED_STRING: INBOX.Assodom
READ: EOL
WRITE: * FLAGS ($MDNSent NonJunk $Forwarded $label4 $label5 $label1 $label2 
$label3 \Draft \Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS ($MDNSent NonJunk $Forwarded $label4 $label5 $label1 
$label2 $label3 \* \Draft \Answered \Flagged \Deleted \Seen)] Limited
* 1086 EXISTS
* 1 RECENT
* OK [UIDVALIDITY 1291488572] Ok
* OK [MYRIGHTS "acdilrsw"] ACL
1120 OK [READ-WRITE] Ok

NB:  This log was rather soon after I started adding that keyword.
Newer logs show it for the folder too, for example:
READ: NUMBER: 10111
READ: ATOM: SELECT
READ: QUOTED_STRING: INBOX.Assodom
READ: EOL
WRITE: * FLAGS ($MDNSent NonJunk nopass $Forwarded $label4 $label5 $label1 
$label2 $label3 \Draft \Answered \Flagged \Deleted \Seen \Recent)
* OK [PERMANENTFLAGS ($MDNSent NonJunk nopass $Forwarded $label4 $label5 
$label1 $label2 $label3 \* \Draft \Answered \Flagged \Deleted \Seen)] Limited
* 1098 EXISTS
* 2 RECENT
* OK [UIDVALIDITY 1291488572] Ok
* OK [MYRIGHTS "acdilrsw"] ACL
10111 OK [READ-WRITE] Ok

I continue with the older log, because I had annotated the UID:
READ: NUMBER: 1121
READ: ATOM: MYRIGHTS
READ: QUOTED_STRING: INBOX.Assodom
WRITE: * MYRIGHTS "INBOX.Assodom" "acdilrsw"
1121 OK MYRIGHTS completed.

READ: NUMBER: 1122
READ: ATOM: GETQUOTAROOT
READ: QUOTED_STRING: INBOX.Assodom
WRITE: * QUOTAROOT "INBOX.Assodom" "ROOT"
* QUOTA "ROOT"
1122 OK GETQUOTAROOT Ok.

READ: NUMBER: 1123
READ: ATOM: UID
READ: ATOM: FETCH
READ: ATOM: 1:*
READ: LPAREN
READ: ATOM: FLAGS
READ: RPAREN
READ: EOL
WRITE: * 1 FETCH (UID 1 FLAGS (\Seen NonJunk))
* 2 FETCH (UID 2 FLAGS (\Seen $label1))
* 3 FETCH (UID 3 FLAGS (\Seen $label1 NonJunk))
  ...
* 1083 FETCH (UID 4311 FLAGS (\Seen NonJunk))
* 1084 FETCH (UID 4312 FLAGS (\Seen NonJunk))
* 1085 FETCH (UID 4317 FLAGS (\Seen))
* 1086 FETCH (UID 4359 FLAGS (\Recent))
1123 OK FETCH completed.

At that point, "nopass" on 4359 was already lost.

The thread continued thus:
READ: NUMBER: 1124
READ: ATOM: UID
READ: ATOM: FETCH
READ: NUMBER: 4359
READ: LPAREN
READ: ATOM: UID
READ: ATOM: RFC822.SIZE
READ: ATOM: FLAGS
READ: ATOM: BODY.PEEK
READ: LBRACKET
READ: ATOM: HEADER.FIELDS
READ: LPAREN
READ: ATOM: From
READ: ATOM: To
READ: ATOM: Cc
READ: ATOM: Bcc
READ: ATOM: Subject
READ: ATOM: Date
READ: ATOM: Message-ID
READ: ATOM: Priority
READ: ATOM: X-Priority
READ: ATOM: References
READ: ATOM: Newsgroups
READ: ATOM: In-Reply-To
READ: ATOM: Content-Type
READ: ATOM: delivered-to
READ: RPAREN
READ: RBRACKET
READ: RPAREN
READ: EOL
WRITE: * 1086 FETCH (UID 4359 RFC822.SIZE 3627 FLAGS (\Recent) 
BODY[HEADER.FIELDS ("From" "To" "Cc" "Bcc" "Subject" "Date" "Message-ID" 
"Priority" "X-Priority" "References" "Newsgroups" "In-Reply-To" "Content-Type" 
"delivered-to")] {365}
Delivered-To: [...field data...]
Delivered-To: [...field data...]
Message-ID: [...field data...]
Date: [...field data...]
From: [...field data...]
To: [...field data...]
Subject: [...field data...]
Content-Type: [...field data...]

)
1124 OK FETCH completed.

READ: NUMBER: 1125
READ: ATOM: UID
READ: ATOM: FETCH
READ: NUMBER: 4359
READ: LPAREN
READ: ATOM: UID
READ: ATOM: RFC822.SIZE
READ: ATOM: BODY.PEEK
READ: LBRACKET
READ: RBRACKET
READ: RPAREN
READ: EOL
WRITE: * 1086 FETCH (UID 4359 RFC822.SIZE 3627 BODY[] {3627}
WRITE: [...message content...]
WRITE: )
1125 OK FETCH completed.

READ: NUMBER: 1126
READ: ATOM: IDLE
READ: EOL
WRITE: + entering ENHANCED idle mode
READ: ATOM: DONE
WRITE: 1126 OK IDLE completed

READ: NUMBER: 1127
READ: ATOM: UID
READ: ATOM: STORE
READ: NUMBER: 4359
READ: ATOM: +FLAGS
READ: ATOM: NonJunk
READ: RPAREN
READ: EOL
WRITE: * 1086 FETCH (UID 4359 FLAGS (\Recent NonJunk))
1127 OK STORE completed.

All the other folders have only a few messages flagged "nopass".  I
didn't check each and every message, but the ones I checked in the
other folders were correct.  Yesterday evening I quit thunderbird,
and this morning all new messages in "INBOX.Assodom" are correctly
flagged "nopass".

The specs for courierimapkeywords look quite complicated, and IIRC
there are other occasions where files get renamed.  In order to catch
the precise operation where the flag gets lost, I think I should run a
script on the server that simulates thunderbird behavior on an unused
folder, checking courierimapkeywords  after each step.  That would be
quite a drag to prepare, though.  Any idea?

-- 

















































------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire 
the most talented Cisco Certified professionals. Visit the 
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
_______________________________________________
courier-users mailing list
courier-users@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

Reply via email to