Hi > [snip] >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. > > listen on lo0 bounce all-content > listen on fxp0 bounce headers-only > > accept from any for domain poolp.org deliver to maildir > accept from any for domain opensmtpd.org deliver to maildir > >in this case, mail to @opensmtpd.org will have a different bounce >strategy depending on the interface used to connect, but once >connected to a specific interface, the bounce strategy will be the >same for all domains. > > >if at the rule-level, we decide that we can apply this to a specific >domain but not another, so more granularity ... > > listen on lo0 > listen on fxp0 > > accept from any for domain poolp.org deliver to maildir bounce all-content > accept from any for domain opensmtpd.org deliver to maildir bounce > headers-only > >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 > > >I favor the second one because using tags we can achieve hybrid models: > > listen on lo0 tag LOCAL > listen on fxp0 tag EXTERNAL > > accept tagged LOCAL from any for domain poolp.org deliver to maildir bounce > all-content > accept tagged EXTERNAL from any for domain poolp.org deliver to maildir > bounce headers-only > >where a single domain can have different policies depending on the >interface it accepted mail from.
I like this (the second) model as I want to control DSN generation by destination as well as source. Or the fully mixed model where there are global defaults overridden by this sort of syntax > [snip] Many thanks JC -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
