See comment here: https://github.com/InterLinked1/lbbs/blob/030576e8fb585868a16f45fd1464565eb786b794/nets/net_smtp.c#L2793
/*! \todo BUGBUG For DIRECTION OUT, if we REDIRECT, then DISCARD, we'll just drop here and forward won't happen (same for REJECT) */
Part of the problem here is that the way the message processor works, we store everything we want to do in a structure and then carry it out afterwards. Currently, in the case of drop, anything that involves delivery anywhere won't actually happen. One way of fixing this might be to drop all the existing recipients if we detect a DROP rule, so that the FORWARD in conjunction would disable the normal drop processing and continue, but only to the desired recipient.
An obvious problem is we can't at present distinguish between the original recipients, and recipients that were added by further rules.
Alternately, if we processed everything as soon as a MailScript or Sieve rule was processed, in realtime, that would alleviate some of these issues. This would probably be more elegant for several of the reasons discussed here.
At the same time, not everything can be done immediately in realtime. For example, FILETO / ADDFLAG probably does need to be stored and processed later as things are now. But some things, and FORWARD, in particular, should probably be processed in realtime, rather than being done at the end. An advantage of this is that we can also change the MAIL FROM just for that delivery, which would alleviate some of the issues discussed in [LBBS-70]
You must be