-
Notifications
You must be signed in to change notification settings - Fork 6
Description
A lot of operations rely on the status of the (recipient) messages. For instance:
- listing the messages in the interface ("Mail blocked" section)
- authorizing / restoring / banning / deleting messages
- sending human authentication and report emails
However, it's actually very hard to determine the exact status of an email, which can be: untreated, banned, authorized, deleted, in error, restored, spam, or virus. The reason is that we must deal with the data from Amavis + a special field status_id: these different information can be out of sync depending on if the mail has been blocked by Amavis, or immediately delivered.
We think that we can drop the status_id field by changing the Amavis columns values:
- on authorizing, change
ds = 'P'andwl = 'Y' - on restoring, change
ds = 'P' - on banning, change
bl = 'Y' - on deleting, juste delete the message (we're still considering this option)
If we do this reliably, we could then get the message status with the following conditions:
- authorized:
ds = 'P' and wl = 'Y' - restored:
ds = 'P' and wl != 'Y' - virus:
ds != 'P' and content = 'V' - banned:
ds != 'P' and content != 'V' and bl = 'Y' - spam:
ds != 'P' and content != 'V' and bl != 'Y' and bspamLevel > domain.level - untreated:
ds != 'P' and content != 'V' and bl != 'Y' and bspamLevel <= domain.level
We can distinguish two opposing groups:
- delivered emails: authorized, restored
- undelivered emails: banned, virus, spam, untreated
Within the "delivered" group, the "authorized" condition is strictly the opposite of the "restored" condition. And within the "undelivered" group, each status is calculated by excluding the condition of the previous one. Said otherwise, the virus condition has the priority over the banned condition, which has the priority over the spam condition, which has the priority over the untreated condition.
This way, we can't have a situation where a recipient message would have no status, nor can we have a message that would have two different statuses.
The first step of this ticket would be to update the ds, wl and bl fields on the authorizing/restoring/banning actions.
Also, we must answer the question of completely deleting the message from the database on the "delete email" action, or not. If the answer is "no", we would have to keep a custom field (maybe deleted_at) and adapt the conditions of the undelivered statuses.