5.2.0-git
04/18/2014

[#11798] RenameSentmailMonthly task not run
Summary RenameSentmailMonthly task not run
Queue IMP
Queue Version Git master
Type Bug
State Duplicate
Priority 1. Low
Owners jan (at) horde (dot) org, slusarz (at) horde (dot) org
Requester jan (at) horde (dot) org
Created 12/01/2012 (503 days ago)
Due
Updated 04/16/2013 (367 days ago)
Assigned 12/03/2012 (501 days ago)
Resolved 04/16/2013 (367 days ago)
Milestone
Patch No

History
04/16/2013 04:33:59 AM Michael Slusarz State ⇒ Duplicate
Milestone ⇒
 
04/09/2013 07:51:42 PM Michael Slusarz Comment #15 Reply to this comment
Duplicate of #11518?
03/05/2013 05:07:34 PM Michael Slusarz Comment #14 Reply to this comment
I tried to track it further down. The task itself is running fine, 
if changing the interval to EVERY. The confirmation screen is 
displayed too, if the interval is either EVERY or MONTHLY. I still 
have no idea why it's not running the task if interval is MONTHLY.
This is sounding more like a general LoginTasks issue (read: 
framework) rather than anything to do with IMP and/or sentmail 
renaming(?)
03/05/2013 04:44:50 PM Jan Schneider Comment #13 Reply to this comment
I tried to track it further down. The task itself is running fine, if 
changing the interval to EVERY. The confirmation screen is displayed 
too, if the interval is either EVERY or MONTHLY. I still have no idea 
why it's not running the task if interval is MONTHLY.
03/03/2013 03:26:23 AM Michael Slusarz Comment #12
Milestone ⇒ 6.0.5
Reply to this comment
What's the status on this?  This needs to be fixed or closed before 6.0.5.
01/10/2013 08:39:50 PM Michael Slusarz Comment #11 Reply to this comment
At the other side, it's maybe a good idea to have a fallback for 
imap servers not totally following the RFC standard.
But not in this case.  Your server is returning BAD.  That means that 
the IMAP command is fundamentally broken to that server and will NEVER 
be successful.

We're not going to unilaterally ignore an IMAP server returning a BAD 
response in all cases just because a single lightly-used IMAP server 
is broken.
01/08/2013 10:10:42 PM evb (at) ping (dot) be Comment #10 Reply to this comment

[Show Quoted Text - 30 lines]
I posted your response to the devs of hmailserver.
Wait and see their response...

At the other side, it's maybe a good idea to have a fallback for imap 
servers not totally following the RFC standard.

01/08/2013 08:19:07 PM evb (at) ping (dot) be Comment #9 Reply to this comment

[Show Quoted Text - 15 lines]
Ok, I see why he wants to create Jan 2012.

The latest successfull creation of a sent map was INBOX.Sent-12-2011.
I remember to have read that normally 3 chars where used for the 
month, correct?
Was it changed in the code from digits to chars around the end of 2011?

01/08/2013 07:48:04 PM Michael Slusarz Comment #8 Reply to this comment
See attachment for logging information.
Your IMAP server is broken.  IMP is issuing:

10 UID COPY 1:50 "INBOX.Sent-jan-2012"

Your server is responding with

10 BAD The folder could not be found.

This is incorrect.  If INBOX.Sent-jan-2012 can be created, the 
response MUST be:

10 NO [TRYCREATE] The folder could not be found.

Your server is 1) incorrectly returning BAD and 2) not returning the 
TRYCREATE response code.

From RFC 3501 [6.4.7]:

       Unless
       it is certain that the destination mailbox can not be created, the
       server MUST send the response code "[TRYCREATE]" as the prefix of
       the text of the tagged NO response.  This gives a hint to the
       client that it can attempt a CREATE command and retry the COPY if
       the CREATE is successful.

Since I've been yelled at multiple times over on the imap list for 
trying to support broken IMAP server installations, I'm hesitant to 
try to workaround this issue in code.
01/08/2013 07:40:43 PM Michael Slusarz Comment #7 Reply to this comment
When rereading the log file, I see also that he is searching 
"INBOX.Sent-jan-2012"
--> 2012??  Should it not be 2013?
No.  You have at least 1 message from Jan 2012 in your current Sent 
mailbox.  e.g.:
  "IMAPD"        3440        3985        "2013-01-02 21:32:42.109"     
    "192.168.1.34"        "SENT: * 1 FETCH (UID 1 INTERNALDATE " 
2-Jan-2012 13:52:00 +0100")"

So this message (and others from Jan 2012) will be moved into a Jan 
2012 sent mailbox.  Doesn't make any sense to move into a Jan 2013 
sent mailbox since those messages have nothing to do with Jan 2013 
(other than the login task being performed during that month, which is 
not tremendously useful information to be used in the future).
01/07/2013 08:17:01 PM evb (at) ping (dot) be Comment #6
New Attachment: Probleem horde rename sent folder.txt Download
Reply to this comment
I have this problem already for several versions of Horde.
Don't remember at which version the task was not executed anymore.

See attachment for logging information.

When rereading the log file, I see also that he is searching 
"INBOX.Sent-jan-2012"
--> 2012??  Should it not be 2013?
01/02/2013 10:12:47 AM Jan Schneider Comment #5 Reply to this comment
Still doesn't work for me. Need to track it down.
12/28/2012 06:06:30 PM Jan Schneider Comment #4 Reply to this comment
I'll let you know on New Year's Day ;-)
12/11/2012 07:52:16 PM Michael Slusarz Comment #3 Reply to this comment
ping?
12/04/2012 04:00:14 AM Michael Slusarz Assigned to Jan Schneider
 
12/03/2012 04:47:58 AM Michael Slusarz Comment #2
State ⇒ Feedback
Reply to this comment
I can't reproduce.  Sentmail task correctly works for me.  I can 
verify that confirmation page causes the task to run, and the task 
correctly moves old sentmail messages to the new mailboxes.
12/01/2012 09:10:49 AM Jan Schneider Comment #1
State ⇒ Assigned
Patch ⇒ No
Milestone ⇒
Assigned to Michael Slusarz
Queue ⇒ IMP
Summary ⇒ RenameSentmailMonthly task not run
Type ⇒ Bug
Priority ⇒ 1. Low
Reply to this comment
I get the confirmation screen, but the task is not executed.