On Sun, Feb 20, 2005 at 06:17:52PM -0800, Robert Spier wrote: > > I think it was better the first time. The two behaviors are > > isomorphic except in returning one different value for one different > > input. If it required a backwards-incomptible change in the config > > syntax it'd be another matter, but this seems a natural extension to > > what the plugin did before which contradicts no other extensions I > > can anticipate. > > Yes, but it complicates an existing very simple plugin.
By a few lines. I find that much easier to accept, in terms of complexity, than subclassing the plugin and introducing a new config file. > A compromise is still two files - with an additional argument to the > plugins file for DENY or DENYHARD. Or instantiate the same plugin twice and make the failure code and bad-address file configurable, yes. > > It's also fits well with sendmail's /etc/mail/access file, which (though I > > dont' care for the conflation in lookup key) enables particular entries to > > trigger various failure codes/messages, enable relaying, etc. > > qpsmtpd != sendmail. > > It's suddenly not badrcptto if it has the power of access. Not that > that functionality is bad, but its scope creep. If thats the > functionality you need, then sounds like someone should create a > 'sendmailaccess' plugin. Didn't say that. The good part about sendmail's access file is essentially what's been suggested, that bits of the same behavior can be adjusted by the same entry in the config file -- reject mail to a given address, adjusted further to rejection with a particular errorcode or even a particular message. A nice feature it enables is the ability to say "we don't take mail from spammers, go away" and "this user has moved, try [EMAIL PROTECTED]" without any particular code to do either. The bad part about sendmail's access file, as I said, is that it conflates multiple forms of lookup, running RCPT-TO access control together with sender-based relay control and other features. Those are inapplicable to bad_rcptto's job and no one's suggesting that we bother with them. -- Devin \ aqua(at)devin.com, IRC:Requiem; http://www.devin.com Carraway \ 1024D/E9ABFCD2: 13E7 199E DD1E 65F0 8905 2E43 5395 CA0D E9AB FCD2
