On Friday 11 March 2011 03:41:03 Chris Lewis wrote: > I think we'd be better served by coming up with, for example, a "qpsmtpd > way" of doing this sort of thing. > > For example: for basic RCPT TO functionality, have a basic RCPT time > plugin that can handle aliasing, allowable domain relays, lists of valid > addresses, tagged addresses etc. Base the plugin around being able to > read a "qpsmtpd format" file specifying all that stuff.
Something like check_rcpts qmail:[qmail specific config specifier] postfix:[postifx config] and the check_rcpts plugin looks for check_rcpts_[system] and calls it (or putting those options into the check_rcpts file itself) Sort of a plugins for plugins idiom... so if you do have a system whereby some users are delivered to qmail and others to postfix then you use both, but most people will just use one or another. Could do the same for delivery systems I expect > Then, have a series of different front-ends for that plugin that can > translate configuration files from other mail platforms into whatever > idiom the RCPT TO plugin understands. I don't think you could feasibly make all such sub-plugins just be "config file readers" as they may have to stay involved. With qmail I can set up aliases so that wildcard matching rules will then consult further files based on the name match - with a file system I could probably walk the entire folders at startup and read all such possible entries, but other systems might not allow such enumeration. > You can even make the "front-ends" plugins of a sort to the hook_rcpt > plugin. Including being able to slip out of the config file paradigm > into, say, custom LDAP/DBMS interfacing for parts of it. I think you're saying the same here... sometimes the sub-plugin will want to defer some of its logic to a later stage. > I think much is to be gained by putting all this MTA functionality (how > you actually _apply_ an alias, handle tagged addresses, etc etc etc) > into _one_ plugin, rather than having to replicate ALL of it into > different plugins written by different people with different skill/bug > levels that in the end only differ as to config file format. If someone comes up with such a system, I'd be more than happy to convert what I've written, but I don't think I've got enough domain knowledge to design it to cover all the options people might want (routing/ordering of checks, interactions of decline/deny semantics between sub-plugins), and I'd hate to leave glaring gaps thru poor choice of design(er). Cheers -- Tim
