Show Advanced KnowledgeHide Advanced Knowledge

Delete old or orphaned mails

1 Description

The mail table may contain data of deleted users. This data could be deleted during the system check. In general the mails are deleted when a user is removed, but Uni Köln reported their mail table contains inconsistent data that might slow down mail access.

Therefore, an optional administration feature to trigger automatic deletion of mails might be useful. For example:

1. A Cron-Job that deletes mails that are older than XX days
2. A button that deletes mails older than XX days
3. A checkbox to control if the settings only affects mail on the INBOX-level (in this case, mails that have been moved to user created folders are not deleted)

2 Additional Information

• Idea / concept: Michael Jansen, Databay AG AG
• Option for funding: Universitätsbibliothek Tübingen
• Development: Feature is to be developed by Databay AG
• Testing: tbd

3 Discussion

JF 19 Apr 2010: We highly appreciate to adress this issue. The adminstration should at least offer a setting "Delete mails older than ..." (via cron job). We do not think that the location in folders should have an effect here. An additional option could allow users to override the time frame individually themselves (but this could be deactivated by the admin if necessary).

Matthias Kunkel, 30 May 2011: Removed from 4.2 feature list due to missing funding. New status is « not scheduled yet ».

MJ 13 Jan 2014: Some further thoughts...
 

• We fear that the whole process around the deletion of mails is opaque to the users and may lead to a data loss. Taking this risk is in our opinion not up to the systems administrators. The data in question are 'expensive' data, handwritten contents and in case of an unwanted deletion, the contents are hard to recover - if at all.
• Maybe we should ignore unread mails and delete only read mails
• In a future implementation we should introcuce something like mail archiving. A user can mark a mail as "archived". Such mails we be ignored during the deletion process.

JF 16 Mar 2015: We appreciate this feature and schedule it for 5.1. An option of the cron job should control if mails are only deleted from trash/inbox. An additional mail should be sent to users to inform them about the upcoming deletion.

4 Implementation

Jansen, Michael [mjansen] 16 Jun 2015:

During the implementation a complete cron job task was built to delete old and orphaned internal ILIAS mails.
This task is listed in the ILIAS Administration under Cron Jobs, can be activated and deactived and its relevant parameters are configurable.
The task was built with a daily interval in mind. The interval cannot be changed. It's important to note that
the ILIAS cron job script must be set up accordingly in the cron daemon of the server.
Users with elevated permissions (according to the permission setup of the ILIAS installation) are able to change settings
as displayed in the mockup above.
Through the definition of a threshold it's possible to define that internal mail will be deleted permanently including attachments if they reach a certain age (given in days).
Relevant is the date of submission (database table mail_data, field send_time). The status of an internal mail - read or unread - is not relevant for the deletion process.
Usesr cannot circumvent the deletion of mails if the cron job task is active.
Furthermore, it can be defined if the deletion process should inspect all folders of the user (inbox, outbox, drafts, trash, own folders) or just inbox/trash.
Optionally, a lead time can be given for the sending of an additional notification that informs the user about internal mails which are going to be deleted soon.
During each cronjob execution a single external mail regarding the deleted internal mails is send as a simple list with the subject line of the internal mail/s.
The notifiction of course  adheres to the following guidline: System Notification Guideline It is worth mentioning that sending this advanced notification is sent with only one day delay at the initial activation or reactivation.
Example:

1. The ILIAS installation holds 50.000 internal mails older than 365 days.
2. The threshold is set to "365" (days).
3. The advanced notification threshold is set to "2" (days).
4. The cron job task is activated and runs on the following night.
5. As there are already 50.000 messages older than the threshold, these would be deleted on the first run as they don't match the advanced notifications age threshold.

To address this problem, during the first run only notifications are sent, the actual deletion is postponed to the second run. We advise to notify the users of ILIAS installations by other means in a timely manner about the activation of the feature.
A user is only notified once about the deletion of an internal mail. This is regardless of the cron job task's status during the period between the notification and the deletion.
Also worth noting: If a user moved a message after receipt of the notification to another folder which is not covered by the deletion process, the message will not be deleted. If the user later moves the message back to a covered folder, it will be deleted without another notification.
The deletion process is only executed with a valid configuration (all mandatory fields have valid values).
The settings for email transmissions from ILIAS should allow for external emails for the affected user accounts. This is relevant for both the configuration of the mail system and the ILIAS permission system. The deletion of internal mails is documented in the ILIAS logfile. Archiving of internal mails is not subject of the feature. Means for manual execution of the process is not implemented due to limited server resources (memory, execution time) in light of the expected workload. The transmission of the notifications to external receipients is done using the ILIAS mail system.

Test Cases

Test cases completed at June 24, 2015 by Matuschek, Nadia [nadia]:

• C5318: Cron Job aktivieren
• C5319: Einstellungen des Cron Jobs
• C5320: Alle Postfächer verarbeiten
• C5321: Nur Posteingang/Papierkorb berücksichtigen
• C5322: Löschen verhindern durch das Verschieben von Mails
• C5323: Nachträgliches Löschen durch das Verschieben von Mails

Approval

Tested successfully and approved at July 2015 by Stefan Rieger.