On Apr 30, 2012, at 11:38 PM, Robert Spier wrote:
> On Mon, Apr 30, 2012 at 1:56 PM, Matt Simerson <m...@tnpi.net> 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).
If you think 'reject 0' is a tolerable idea for rejection plugins, just wait
until you see the joy that can be had when using it with authentication
plugins. Instead of having to edit the source to get authentication
fall-through behavior, it could be configuration based, using that same reject
option. Uncomment your chosen auth plugins, set the last auth plugin to reject
1, and voila!
As far as a plan, I think a sensible default would be for all plugins to
default to not rejecting mail. I also expect such a position to generate a lot
of controversy. After all, no small part of why we use qpsmtpd is to reject
invalid mail.
But...
For new users of qpsmtpd, I think it's better to get excess mail than to
discover that valid mail is being rejected. The former is annoying, the latter
can sow deep seeds of distrust. And then the injured party has to figure out
which plugin or config setting is to blame. And then they have to figure out
how to change the plugins configuration, or disable it entirely. While their
boss is breathing down their neck.
Imagine instead, qpsmtpd is installed out of the gate on the parties computer.
By default, most of the plugins are enabled, all are logging their results, and
all default to reject 0 behavior (except perhaps AV plugins). Because each
plugin logs its disposition consistently, and we include plugin scripts for
munin & nagios, the sysadmin can soon see how many messages were delivered and
how many failed each of the plugin tests. With a little grep action, he can get
satisfy his concerns and curiosity. He might decide to disable a few plugins
because they get so few hits, and he'll certainly be setting reject 1 on a few.
But this user is very sensitive to lost mail so he sets reject 0 reject_type
soft, and then watches the logs for a while to make sure it's doing exactly
what he expects. While doing so, he discovers a nuance of SPF, like the fact
that it rejects forwarded mail unless the forwarding server supports SRS, which
most servers don't. No problem, he can set it back to reject 0 and the deferred
email will get delivered later.
That scenario sounds contrived, but I've run into similar situations dozens of
times.
> 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.
Certainly so!
Think of it this way. If we have a default reject 0 policy for plugins, it's
easy as pie to figure out which ones are configured to reject mail. Just grep
the word reject from config/plugins. Want to institute a BOFH policy? Set
reject 1 reject_type perm on every plugin! <insert evil genius LOL here>
Now the only thing that needs to be documented about rejection in the plugins
are any nuances from standard behavior.
> 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.
And notice that one logging plugin has named arguments, and the other uses a
positional argument. You can bet you'll see a patch to change that in the
future... :-)
> > What's "better?" Better for me is not changing the config.
>
> As I was saying, there's technical ways to allow exactly that. <snip>:
>
> # 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.
I think I'd rather keep that non-sense in the plugin, and perhaps complain
boisterously about it in the logs when used. Put a sunset date when compat
shims are introduced, and eventually they go away.
Matt
