Email purge feature

however a option for Users to click it
Click to expand...

This I agree with since users already have the option to delete their own email. The users should always have the option to delete their email whether its individually or in bulk. The hosts should not take it upon themselves to do this.

Keep in mind you have to switch to dovecot. If you were already using dovecot then the host already had to ability to delete emails older than x days using cronjobs.

The only way you get into trouble is if you don't have a policy
Click to expand...

Trouble is a general term to cover many different aspects, legal only being one of them and where a policy has any effect. A policy will not keep a customer from canceling because a host deleted his email.

There is no difference in this context between wouldn't use and don't want.
Click to expand...

I agree but you missed the point entirely and you will never understand it so I will stop wasting my time trying to help you. I volunteer my time here to help reasonable people, not to argue.
 
IT_Architect said:
All I asked for a something a lot of people need and you came trolling and got caught in your own trap.
Click to expand...

All I asked for is what evidence do you have that a lot of people need it. Sometimes people make big claims that are not true just to get their personal agenda pushed through.

Its ok if its just 1 person or a small number of persons that want a feature. That is why the forum is here. People don't have to puff up the numbers to get DA to consider a feature especially if its easy to implement.
 
Today I used the email purge feature for the first time. And it seems it don't work well.

First at squirrelmail I found a lot of spam in the spamfolder, from today going back to 2007. I then logged in DA, and at the email accounts page I selected the checkbox for the right email account, and at the table footer I choose 'Purge from' > 'Spambox' > 'Older than 356 days'. (Why is that 356 and not 365?)

Going back to squirrelmail, I saw the ALL the spam was deleted. I expected to have left about a year of spam.

Is this a bug or by design?
 
Hello,

I just went through the entire code based for this tool and didn't have any errors with it. My test was as follows
Code: 
[root@server new]# pwd
/home/admin/imap/test.com/char/Maildir/.INBOX.spam/new
[root@server new]# ll
total 8
-rwxr-xr-x  1 admin mail 178 Jul  7 00:28 pack.sh
-rw-r--r--  1 admin mail   5 Nov 25 01:26 test
[root@server new]# ll
total 4
-rw-r--r--  1 admin mail 5 Nov 25 01:26 test
[root@server new]#
Where I just grabbed a random file with an old timestamp and put it into the folder. I created a new file, and put it in the folder. I ran DA in debug mode. Level 600 will give you info on the purging tool. This is the debug output I got from that
Code: 
empty_file_for_user(char, test.com, spambox, 60): days: 60
Emptying /home/admin/imap/test.com/char/Maildir/.INBOX.spam: days=60
                email user /home/admin/imap/test.com/char/Maildir/.INBOX.spam
                                checking pack.sh : no date in name
                        ** Deleting: pack.sh
                                checking test : no date in name
So likely, the only difference between your files and mine would be the "date in name". My random files didn't have timestamps in them, so DA defaulted to using the system timestamp via the stat() function. If there is a timestamp in the filename itself, DA will search for "%d.", meaning the first number it finds that is followed by a dot. That number would be assumed to be the timestamp of the file. If it was an incorrect number, that could explain your missing files.

A sample filename is:
Code: 
1257540811.H855755P781.server.hostname.com:2,S
The timestamp in the filename is "1257540811". If you turn that into human time, it would read "Fri, 06 Nov 2009 13:53:31 -0700", more or less, depending on your timezone, etc...

So any "wrong number" in that time in the filename could be the cause of the file being deleted. If you have backups of your Maildir/.INBOX.spam directory, you could keep reloading the files in there to duplicate the issue repeatedly to get a better picture, then let me know.

Anyway, if you want to run DA in debug mode to see what it's deciding, this feature has a lot of handy debug code for it's decisin making, so that might help figure out what's going on in your case.
Code: 
cd /usr/local/directadmin
killall -9 directadmin
./directadmin b600
then issue the purge on some other account to see what it does.

If anyone else is also noticing weird behavior with this tool, mention it here.

And yes, 356 was a typo, I've changed it to 365 for the next release. It would have resulted in DA doing the code for emails older than 356 days instead of 365.

John
 
For completeness, I've tested again with a more realworld setup using dates in the filenames. This is the before and after shot of the directory:
Code: 
[root@server new]# ll
total 12
-rw-r--r--  1 root  root 10 Nov 25 01:44 1057540811.H855755P781.server.hostname.com
-rw-r--r--  1 root  root  6 Nov 25 01:44 1257540811.H855755P781.server.hostname.com
-rw-r--r--  1 admin mail  5 Nov 25 01:26 test
[root@server new]# ll
total 8
-rw-r--r--  1 root  root 6 Nov 25 01:44 1257540811.H855755P781.server.hostname.com
-rw-r--r--  1 admin mail 5 Nov 25 01:26 test
[root@server new]#
where 1257540811 is Nov 6, 2009, and 1057540811 is July 6, 2003. This is the debug output from my test:
Code: 
empty_file_for_user(char, test.com, spambox, 365): days: 365
Emptying /home/admin/imap/test.com/char/Maildir/.INBOX.spam: days=365
                email user /home/admin/imap/test.com/char/Maildir/.INBOX.spam
                        ** Deleting: 1057540811.H855755P781.server.hostname.com
 
Hello John,

Do I need root access? I don't have root access on the server. Our company is acting as reseller. We do almost all administration through DA.

If we have collected some spam again, I will look for the message date in the source before using the purge tool. If I keep getting problems, I'll contact our provider first. They have root access.

Thanks for now.
 
Hello,

Yes, root is required to run in debug mode.

You can check the timestamp of the file (last write), and the timestamp in the filename via your FileManager.
/imap/domain.com/user/Maildir/.INBOX.spam/new
/imap/domain.com/user/Maildir/.INBOX.spam/cur

John
 
You must log in or register to reply here.
Back
Top