Re: future directions

On Mon, Apr 30, 2012 at 1:56 PM, Matt Simerson <[email protected]> wrote:

>
> On Apr 29, 2012, at 11:45 PM, Michael Papet wrote:
>
> >> As it stands,
> >> there's often no way to answer questions like, 'how much of
> >> my ham will fail this test?' or 'will I lose valid mail
> >> using plugin X?'  It's completely nebulous.
> >
> > When I need this, I use logging.  I flip qpsmtpd into info mode with a
> few extra logging stanzas.  While I see the point in having that feature,
> maybe some extra lines of logging might be more succinct?
>
> If you enable a plugin like require_resolvable_fromhost, then you are
> rejecting all messages that fail the test, including possible valid ones.
> There's already plenty of logging to determine that.
>
>  Without altering the plugin, there's no method for a qpsmtpd admin (who
> is not a perl hacker) to make such a determination until they have already
> rejected valid mail. For some installations, this is a Very Big Deal. By
> adding a 'reject 0' or 'reject no' option, a syadmin can enable the plugin
> with rejections disabled, watch the logs for a time, and then decide
> whether they want to reject based on that information.
>
>
I think I reacted poorly to this initially.  There's nothing wrong with
'reject 0' as long as we don't change the defaults (without a plan).

Plugin wrappers were one solution to this, but obviously a heavyweight and
complicated one.

We do need to be careful about not getting config-itis.  We don't want
people having flashbacks to pre-m4 sendmail configs.



> I have found a solution that accomplishes what I want. Replace the logging
> lines in qpsmtpd/config/plugins with these:
>
>        logging/syslog loglevel LOGERROR
>        logging/warn LOGINFO
>
> Now logging continues to work via multilog (the 'default' method), and
> errors are sent to syslog where standard monitoring tools can pick them up
> and act on them.
>
>
If we had a FAQ. this would be a great thing to put in it.


>  >> Understanding it is a large barrier to entry.
> >
> > If the goal is to expand the userbase, then I think more documentation
> might help.
>
> More != better.
>
> More consistent behavior by plugins would result in less documentation. If
> the same level of understanding can be achieved with less documentation,
> that is a better solution for both users and developers. For example,
> here's a partial sampling of config options that will control whether a
> plugin merely logs, or rejects based on its findings:
>
>   reject_threshhold N
>   reject N
>   warn_only [ boolean ]
>   action [ deny | denysoft | log ]
>
> Each of those has to be documented differently. Instead, any plugin that
> might defer or reject mail should use a 'reject' argument. The options that
> argument can take may vary according to plugin, but a short list could
> cover most needs:
>
>   reject [ score | 1 | 0 | no | yes ]
>
> and possibly:
>
>   reject_type [ temp | perm | hard | soft ]
>
> Those config options are practically self explanatory and cover every use
> case shown. That is far better than having numerous ad hoc ways to
> accomplish the same goal.
>
>
This is reasonable, as long as we have a plan to get there without breaking
existing users.


>
> > What's "better?"  Better for me is not changing the config.
>
>
> As I was saying, there's technical ways to allow exactly that. We can
> change the plugin and the interface and yet still work perfectly with
> legacy config files. That way, plugin authors bear the burden of backwards
> compatibility, not users. For example, I just renamed the spamassassin
> plugin reject_threshhold option to reject. I also added this code in the
> plugin:
>
> # backwards compatibility with previous config syntax
> if ( ! defined $self->{_args}{reject} && defined
> $self->{_args}{reject_threshold} ) {
>    $self->{_args}{reject} = $self->{_args}{reject_threshold};
> };
>
>
We should consider wrapping this in a function, or the currently "simple"
plugins are going to start being a lot more complicated.

$self->alias_args('reject' => 'reject_threshold'); or something.



> Now you can upgrade and your existing config works as you expect.
>

+1

-R