explicitly store in a Message whether it was delivered to the rejects mailbox

soon, we can have multiple rejects mailboxes.  and checking against the
configured rejects mailbox name wasn't foolproof to begin with, because it may
have changed between delivery to the rejects mailbox and the message being
moved.

after upgrading, messages currently in rejects mailboxes don't have IsReject
set, so they don't get the special rejecs treatment when being moved. they are
removed from the rejects mailbox after some time though, and newly added
rejects will be treated correctly. so this means some existing messages wrongly
delivered to the rejects mailbox, and moved out, aren't used (for a positive
signal) for future deliveries.  saves a bit of complexity in the
implementation.  i think the tradeoff is worth it.

related to discussion in issue #50
This commit is contained in:
Mechiel Lukkien
2023-08-09 16:47:29 +02:00
parent 0fc59af9a8
commit 383fe4f53a
9 changed files with 24 additions and 7 deletions

View File

@ -367,6 +367,11 @@ type Message struct {
CreateSeq ModSeq `bstore:"index"`
Expunged bool
// If set, this message was delivered to a Rejects mailbox. When it is moved to a
// different mailbox, its MailboxOrigID is set to the destination mailbox and this
// flag cleared.
IsReject bool
// MailboxOrigID is the mailbox the message was originally delivered to. Typically
// Inbox or Rejects, but can also be a mailbox configured in a Ruleset, or
// Postmaster, TLS/DMARC reporting addresses. MailboxOrigID is not changed when the