5.3.0-git
2014-10-25

[#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 2012-12-01 (693 days ago)
Due
Updated 2013-04-16 (557 days ago)
Assigned 2012-12-03 (691 days ago)
Resolved 2013-04-16 (557 days ago)
Milestone
Patch No

History
2013-04-16 04:33:59 Michael Slusarz State ⇒ Duplicate
Milestone ⇒
 
2013-04-09 19:51:42 Michael Slusarz Comment #15 Reply to this comment
Duplicate of #11518?
2013-03-05 17:07:34 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(?)
2013-03-05 16:44:50 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.
2013-03-03 03:26:23 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.
2013-01-10 20:39:50 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.
2013-01-08 22:10:42 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.

2013-01-08 20:19:07 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?

2013-01-08 19:48:04 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.
2013-01-08 19:40:43 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).
2013-01-07 20:17:01 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?
2013-01-02 10:12:47 Jan Schneider Comment #5 Reply to this comment
Still doesn't work for me. Need to track it down.
2012-12-28 18:06:30 Jan Schneider Comment #4 Reply to this comment
I'll let you know on New Year's Day ;-)
2012-12-11 19:52:16 Michael Slusarz Comment #3 Reply to this comment
ping?
2012-12-04 04:00:14 Michael Slusarz Assigned to Jan Schneider
 
2012-12-03 04:47:58 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.
2012-12-01 09:10:49 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.