1 Topic by sergiocesar

  • sergiocesar
  • Member
  • Offline
  • Registered: 2014-04-28
  • Posts: 94

Topic: delete_mailboxes.py bug

==== Required information ====
- iRedMail version (check /etc/iredmail-release): 0.9.6 MYSQL
- Linux/BSD distribution name and version: Linux 6.8
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL
- Web server (Apache or Nginx): Apache
- Manage mail accounts with iRedAdmin-Pro? No
- Related log if you're reporting an issue:
====
created an account and made a small mistake, deleted it and selected to delete mailbox 1 day.
recreated the account and when the cron job ran it deleted the mailbox.
it seems like the "delete_mailboxes.py" does not verify if the account exist before it deletes it.
Perhaps we need an option to delete mailbox NOW and not store the record on deleted_mailboxes.
BTW. the installation did not create the cron entry as stated here under "improovements" http://www.iredmail.org/forum/topic1226 … eased.html
Assuming that a new installation would also do the same as an upgrade.

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2 Reply by ZhangHuangbin

  • ZhangHuangbin
  • ZhangHuangbin
  • iRedMail Developers
  • Offline
  • Registered: 2009-05-06
  • Posts: 30,770

Re: delete_mailboxes.py bug

*) Did you run "delete_mailboxes.py" manually? If yes, any command line argument did you use?
*) Do you configure iRedAdmin to append timestamp in maildir path?

sergiocesar wrote:

BTW. the installation did not create the cron entry as stated here under "improovements" http://www.iredmail.org/forum/topic1226 … eased.html

How did you upgrade iRedAdmin? Simply copy files from new version and override files in old version?

3 Reply by sergiocesar

  • sergiocesar
  • Member
  • Offline
  • Registered: 2014-04-28
  • Posts: 94

Re: delete_mailboxes.py bug

ZhangHuangbin wrote:

*) Did you run "delete_mailboxes.py" manually? If yes, any command line argument did you use?
*) Do you configure iRedAdmin to append timestamp in maildir path?

sergiocesar wrote:

BTW. the installation did not create the cron entry as stated here under "improovements" http://www.iredmail.org/forum/topic1226 … eased.html

How did you upgrade iRedAdmin? Simply copy files from new version and override files in old version?

I ran it manually:
delete_mailboxes.py --delete-without-timestamp
No, I do not use timestamp. without the argument it error out.

As I said this was a new install not upgrade so I assume it creates the cron entry...

4 Reply by ZhangHuangbin

  • ZhangHuangbin
  • ZhangHuangbin
  • iRedMail Developers
  • Offline
  • Registered: 2009-05-06
  • Posts: 30,770

Re: delete_mailboxes.py bug

sergiocesar wrote:

As I said this was a new install not upgrade so I assume it creates the cron entry...

You're right, it's a bug of iRedMail-0.9.6. Fixed moment ago. Thanks for the feedback.

sergiocesar wrote:

I ran it manually:
delete_mailboxes.py --delete-without-timestamp
No, I do not use timestamp. without the argument it error out.

I believe you already read the comment lines in "delete_mailboxes.py", "--delete-without-timestamp" is risky.

#   * --delete-without-timestamp:
#       [RISKY] If no timestamp string in maildir path, continue to delete it.
#
#       With default iRedMail settings, maildir path will contain a timestamp
#       like this: <domain.com>/u/s/e/username-<20160817095303>/
#       (20160817095303 is the timestamp), this way all created maildir paths
#       are unique, even if you removed the user and recreate it with same
#       mail address.
#
#       Without timestamp in maildir path (e.g. <domain.com>/u/s/e/username/),
#       if you removed a user and recreate it someday, this user will see old
#       emails in old mailbox (because maildir path is same as old user's). So
#       it becomes RISKY to remove the mailbox if no timestamp in maildir path.

5 Reply by sergiocesar

  • sergiocesar
  • Member
  • Offline
  • Registered: 2014-04-28
  • Posts: 94

Re: delete_mailboxes.py bug

ZhangHuangbin wrote:

#       Without timestamp in maildir path (e.g. <domain.com>/u/s/e/username/),
#       if you removed a user and recreate it someday, this user will see old
#       emails in old mailbox (because maildir path is same as old user's). So
#       it becomes RISKY to remove the mailbox if no timestamp in maildir path.

Yes I understand that. It is much easier to deal with mailboxes that are directly listed under the domain folder. we see no reason to have it buried down several levels when we are trying to troubleshoot an issue.  <domain.com>/u/s/e/username/
<domain.com>/username<timestamp>/ should suffice.
On the other hand, for legal reasons we do not keep any emailbox data after the user is deleted, iRedmail provides no means of deleting a box immediately so we had in the past to manually dig and delete the box.
We had this discussion before where you said that in some countries one must keep the boxes for ever or some time, well in my area if we do, we may be at risk and violation as the box does not belong to the hosting house and must be removed from the servers.
I really liked the script as I can automatically delete soon after the box is deleted but would like even more if the option to delete immediately was available and even if we could set so it is the only option. That would assure our immediately compliance.

One suggestion.
In many cases the customers is the one adding and deleting users, I had several requests to provide the data in a compressed file. It would be nice to provide a way so they can delete a box, with an option to backup the file into a web accessed folder and email a one time link to download the file. That way if the user want the data they can have it and we providers dont have to manually do this.

6 Reply by ZhangHuangbin

  • ZhangHuangbin
  • ZhangHuangbin
  • iRedMail Developers
  • Offline
  • Registered: 2009-05-06
  • Posts: 30,770

Re: delete_mailboxes.py bug

sergiocesar wrote:

I really liked the script as I can automatically delete soon after the box is deleted but would like even more if the option to delete immediately was available and even if we could set so it is the only option. That would assure our immediately compliance.

I understand your point.

Since this delete_mailboxes.py is ran by cron job, so the minimal day is 1 day. That's why we don't have a "delete immediately" option. But maybe you can run it in cron job with shorter interval, e.g. every 1 hour, if there's new entry in sql table "deleted_mailboxes", delete them immediately.

sergiocesar wrote:

In many cases the customers is the one adding and deleting users, I had several requests to provide the data in a compressed file. It would be nice to provide a way so they can delete a box, with an option to backup the file into a web accessed folder and email a one time link to download the file. That way if the user want the data they can have it and we providers dont have to manually do this.

So your request is "Backup whole mailbox before actually deleting it"?

I think it's easy to do backup-then-delete, the problem is how to store the backup copy and notify domain admin. Should we simply send email to notify 'postmaster@<client domain>' directly?

Any suggestions?