On Wed, Mar 5, 2014 at 2:33 AM, Jason A. Donenfeld <[email protected]> wrote: > 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?
Gilles -- Any thoughts? -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
