On Wed, Mar 5, 2014 at 1:44 AM, Gilles Chehade <[email protected]> wrote: > if at the listen-level, we decide that it is not possible to have the > mechanism apply to a specific domain, it applies to all domains that > will be match on that interface. > if at the rule-level, we decide that we can apply this to a specific > domain but not another, so more granularity ... > in this case, it is when an envelope matches a rule that we decide which > strategy we want to use. two different domains accessed from the same > interface may have different policies. > I favor the second one because using tags we can achieve hybrid models:
> as knobs for global default overrides, which can be overriden at the > rule level, like we do for "expire" All good points, and I'm inclined to agree with you that we receive some nice granularity by doing it on accept rather than on listen (since you've already solved the context issue I mentioned). One further suggestion along the same lines as your preference: What about unifying the global override with the rule-based config, to have one line that's something like: bounce from [email protected] with-body expire 4d bounce to [email protected] only-headers expire 5w bounce to @blah.org only-headers expire 20m bounce from @where.org with-body expire 8d bounce only-headers expire 1d And this would use the same rule based "first match" logic as all others. The precise meanings of "to" and "from" will need to be refined a bit further, but this is the general idea. What do you think of that? -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
