Anders wrote:
Well, I got another report about a 1970 timestamp :-(.
Now I have enabled rawlog for all users that are still on Procmail delivery. Will this be useful? Is there something else that I can do?
Hi. I now caught this issue once with rawlog. I hope Squirrelmail does not mangle it too badly:
============ In
mkl5 IDLE DONE g6uu UID FETCH 18660:* (UID FLAGS RFC822.SIZE BODY.PEEK[HEADER] INTERNALDATE) ppj9 IDLE DONE
============ Out
- idling
- 15 EXISTS mkl5 OK Idle completed.
- 15 FETCH (UID 18660 FLAGS () RFC822.SIZE 0 INTERNALDATE "01-Jan-1970 00:00:00 +0000" BODY[HEADER] NIL) g6uu OK Fetch completed.
- idling
- OK Still here ppj9 OK Idle completed.
============
Doing the same FETCH by hand now gives the right information.
It seems that whenever this problem shows up, two messages are delivered at roughly the same time, and it is the later one that has its information zeroed out. Here is stat(1) output from the message above, and the one that arrived right before it:
File: `1212044868.8445_0.mail:2,' Size: 6331 Blocks: 16 IO Block: 4096 regular file Device: fd00h/64768d Inode: 124977206 Links: 1 Access: (0600/-rw-------) Uid: ( 5000/ vmail) Gid: ( 5000/ vmail) Access: 2008-05-29 09:42:59.000000000 +0200 Modify: 2008-05-29 09:07:48.000000000 +0200 Change: 2008-05-29 09:22:30.000000000 +0200
File: `1212044877.8482_0.mail:2,S' Size: 6242 Blocks: 16 IO Block: 4096 regular file Device: fd00h/64768d Inode: 124977209 Links: 1 Access: (0600/-rw-------) Uid: ( 5000/ vmail) Gid: ( 5000/ vmail) Access: 2008-05-29 09:42:59.000000000 +0200 Modify: 2008-05-29 09:07:57.000000000 +0200 Change: 2008-05-29 09:23:53.000000000 +0200
Nine seconds is well above the time spent delivering a message on this server.
Cheers, Anders.