On Fri Jun 01, 2012 at 18:40:04 -0700, Matt Simerson wrote: > But reducing code and simplifying plugins is just as important. This > implementation adds more control and flexibility to plugins without > additional code. For example, now it's possible (without writing code) > to configure all plugins to reject early or late by setting them all > to <reject zombie>.
Sure. (At the cost that you have a new dependency.) > I think moving the conditions for bypassing plugin processing into a > centralized is_immune() method as I have done is substantially more > general. You could be right :) > It means adding only a single line of code to each plugin, > and is_immune isn't specific to any single note. It works equally well > for whitelists, relay clients, your rejects, and my zombies. Yes that is certainly true, but I don't often get swayed by the count of code lines! I'm sure you'd agree that the gain you're seeing here is from consistency as much as anything else. In the same way that I used/use "reject" I could do similar things. > I obviously like the rejected idea. I don't like the 'rejected' note > name though, because the rejected term is already overloaded. It means > many different things in different contexts within qpsmtpd. The name was born from the notion that a mail is either rejected for delivery or accepted. But I absolutely agree that it is another usage. > Why hasn't your rejected idea been worked into qpsmtpd yet? Because I came to view qpsmtpd in a different way than many do (many view it as a service with useful plugins which they can deploy, use, and enjoy). Instead I view it more as a framework for rejecting/processing/handling mail that happens to come with some nice sample code. You will know, more than most, that the included plugins are a mixture of useful and silly, are written beautifully and horribly, and basically lack any cohesion and consistency. I've submitted a few minor cleanups, but I could never quite be motivated enough to rewrite/update all the plugins to make them more consistent. Instead I chose to lay down my own rules, e.g. use "rejected" as a note globally, and write a set of plugins that worked well together from the start. Were qpsmtpd to be written *now* I'm sure there would be a greater push on standardization of the core plugins, a documentation of the expected inter-plugin-note-names, etc. Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/
