Wietse - Thank you for explaining your position on this in so much detail! You definitely have a pretty strong and reasonable opinion here. I was essentially after mail filtering capabilities analogous to those of a network packet filter and I felt that those would reasonably fit into Postfix proper, but indeed I accept your opinion that they don't.
I've included some comments below. These are not meant to argue with you, but merely to communicate my thoughts on the matter, even though these probably do not matter as you've already made the determination. On Thu, Nov 17, 2011 at 11:38:02AM -0500, Wietse Venema wrote: > Let's for a monent look at what the system does well and why. The > system is designed for blocking stuff. There are N rule sets that > can block/discard independently (smtpd_client_restrictions etc., > header_checks etc.,). If any of them blocks, mail is not queued. > It's a vetoing system. All the other actions such as filter or > redirect are just riding along on the train. Agreed. > This model is a good fit for vetoing. If is a poor fit for lots of > other things including 1) conditional decisions and 2) "don't reject" > decisions that override other rulesets. Yes. > So let's not do that. OK, yet I felt that we could do a little bit of that at one specific layer only. > You have a need for conditional decisions, which could be modeled > as a "maybe reject" action that only takes effect if some other > action (accept) in the same rule set does not fire. Right. > But why stop here? Why not have "maybe filter", "maybe redirect", > and so on that are also dependent on the absence of some other > action (what other action? OK, so we do "ifnot accept reject", > "ifnot filter redirect", etc. to make the condition explicit. > Yes, it is possible. No, it is not a good idea. The resulting > system would be an incomprehensible mess. Yes, I had these thoughts/concerns, too. I think I'd stop at supporting those other default actions, but not adding the if/ifnot logic at that level. For such logic, if desired, I had proposed MARK actions and matching on marks and not-marks. This would be similar to the way in which and to extent to which network packet filters may be configured. Individual header/body lines may be analogous to individual network packets, and messages to network connections. State from line (packet) matches may be passed onto decisions for messages (connections). I felt that this would not be too hard and too messy to implement on top of what we readily have in Postfix. > In addition you have a need for a positive decision (already a poor > fit for a vetoing system!) in one rule set to override decisions of > other rulesets (here, an accept in header_checks that overrides > rule sets that happen to be co-located in the cleanup daemon). I feel that header_checks and body_checks are very closely related to each other (and share code). I think it could be reasonable to consider them one ruleset, within which this packet filter like logic would be present. In fact, they're even documented in just one man page. > I'm not saying that your needs are wrong. I am saying that you > need to use a model that is a good fit. It would be a mistake to > change a model that is a poor fit, such as a veto-based system. Maybe, but it's tempting to enhance the existing model if it can be done with little complexity to the code. > It is very well possible that your needs require a model with rules > that have precedences. For example, one receives the entire message, > and applies all the rules in order of precedence and stops at the > first final decision (ACCEPT or REJECT). I don't have an immediate need for that, but, yes, it would arguably resemble a network packet filter more closely. On the other hand, with the messages-connections analogy, I'd have to use MARKs either way and not care about the order of lines-packets. > Postfix does not work that way. It does not have to solve all > problems. That is what the extension interfaces (including SMTP) > are for. I definitely agree that Postfix should not (and can not) solve all problems. The question is where to stop. I felt that minor additions to the existing feature set and code, yet that would make the built-in filtering sufficient in a lot more cases, would be appropriate. You have pointed out that this would cross some boundaries unrelated to Postfix code complexity. I accept this. Thanks again, Alexander
