Generic conditions and filtering for SMTP pipeline about maddy HOT 6 CLOSED

Generic conditions syntax
match => if

LGTM

This filtering is necessary due to the fall-through nature of the pipeline (deliver statement does not stop processing).

Ugh, don't we have a stop directive too?

As a consequence, in the following example, maddy MTA will connect to itself and deliver email twice.

Hmm, I don't get why? If it takes a branch, it won't take the other?

deliver [filter conditions] target [options]

Maybe it'll be worth it to use an alternate form to filter, e.g.:

deliver {
    filter <filter1> <filter2>
    target <target>
}

Combined examples

Seems like there are duplicate conditions/filters here

from maddy.

Hmm, I don't get why? If it takes a branch, it won't take the other?

Let's say we are emersion.fr and we got a message with two recipients: [email protected] and [email protected].
And we have this pipeline definition:

submission smtps://0.0.0.0 {
  hostname emersion.fr
  if rcpt_domain = "emersion.fr" {
    deliver local
  }
  if rcpt_domain != "emersion.fr" {
    deliver remote
  }
}

if rcpt_domain = "emersion.fr" => true ([email protected]), execute subblock
deliver local => local delivery module gets message with two recipients (problem 1)

if rcpt_domain != "emersion.fr" => true ([email protected]), execute subblock
deliver remote => remote delivery modue gets message with two recipients (problem 2)

Problem 1

What should local delivery module do with [email protected]? Try to save to local foxcpp account? Ignore? Fail because of a non-local domain?

If we decide to just ignore - we are limiting the flexibility of pipeline functionality (and as a consequence - entire maddy). What if we have two domains we want to share the same accounts? It would make a lot of sense to have a single mail server for them. This raises a question about how to define what is local and what is not. My proposal solves this in a generic way which also allows describing more complex combinations (like, have different storage for different domains, forward messages for certain accounts to a different server, etc).

Problem 2

What should remote delivery module do with [email protected]? Deliver to emersion.fr (us, basically). Ignore? Fail because of local domain?

...

While writing that I got another idea how to filter envelope information in pipeline: combine filter definitions with if blocks.

if rcpt_domain = "emersion.fr" {
  deliver local  # local delivery module will see only recipients with the local domain
}
if rcpt_domain != "emersion.fr" {
  deliver remote # remote delivery module will see only recipients with non-local domains
}

Well, I often come up with suboptimal solutions) What do you think? Perhaps you have a better idea of what to do here.

from maddy.

Another variant:
Introduce destination directive as in #14 and leave if for more low-level dispatching.

destination emersion.fr { 
  delivery local # sees only recipients with the emersion.fr domain, not called if there are no such recipients
}

Here, in destination argument you can either emersion.fr (just recipient domain), [email protected] (full address) or /regexp/ that should match full address.

from maddy.

I guess we can make use of this: https://github.com/antonmedv/expr

from maddy.

Reconsidering this proposal in the light of expr library I linked above (which is very good, I think).

Since expression is a single string, it's tempting to just accept it as an argument. This requires it to be wrapped in quotes since the expression will most definitely contain whitespace. This leads to another problem: expr uses quotes for string literals.

This will look quite messy:

if "\"[email protected]\" in To" {
 // ...
}

Instead, I propose to finally copy config lexer from caddy repo and include it here.
Then, add flag to the token indicating that it was constructed from a quoted string.
This would let users write expressions like that:

if "[email protected]" in To {
}

We join arguments, readd quotes stripped by lexer and construct the following expression that then will get passed to expr library: "[email protected]" in To.

Wdyt?

from maddy.

Makes sense to me.

from maddy.