Skip to content

Rationalise the calculation of recipient message statuses #317

@marien-probesys

Description

@marien-probesys

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' and wl = '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:

  1. delivered emails: authorized, restored
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions