On Tue, Mar 04, 2014 at 12:25:58AM +0100, Jason A. Donenfeld wrote: > > [...] > > OpenSMTPD will generate bounces in lots of contexts. It doesn't make > sense, for example, to add the flag to "accept", since if you accept > mail for @poolp.org, but ploop.org also points to the same IP, and > someone sends a message to [email protected], opensmtpd will generate > a bounce. This bounce doesn't exist in the context of that 'accept' > line, so it wouldn't really make sense to have the control there. > OTOH, all messages necessarily go through a "listen" line, and exist > in that context, so I think a flag would make more sense there. >
That's not an issue really, wether you handle this at the listen level or at the rule level, we know how to cope with contexts easily as this tricky problem has been solved already for cross rule aliases resolve. Let's ignore this and focus on what we want, context aside. The main reason for chosing one over the other is the granularity: 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 interface may have different policies. 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. > listen on lo ... [absence of no-bounce-bodies] > listen on eth0 ... no-bounce-bodies > > or, to be 'safe' by default (which is arguably better): > > listen on lo ... bounce-bodies > listen on eth ... [absence of bounce-bodies] > > > Put this way, it would mean that when a local user queues up a message > and sends it, and that message bounces, that local user receives the > full body in his bounce. And contrarily, when an external host > connects to send a message that bounces, the body is not sent, to > prevent against this backscatter problem. > as explained above, I think it can be achieved nicely at a rule level > Or, maybe that's much too complex, and breaks with the pattern > introduced by "bounce-warn", which is a global config option. This > would probably be much easier to grok. This would look like: > > listen on eth0... > listen on lo... > accept for ... > bounce-warn 3m > bounce-parts headers body > or > bounce-parts headers > or > bounce-parts body > > > Even better, the two bounce options could be unified into one line > with simpler grammer: > > bounce warn-wait 3d with-body with-headers > > Or something similar. > actually what we could do is some kind of mix: bounce-warn bounce-parts as knobs for global default overrides, which can be overriden at the rule level, like we do for "expire" -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
