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.
For perl hackers, that information can be used later in another plugin.
Everybody wins.
>>> I also think logging anything more severe than a WARN
>> event should have the option to automatically email a sysadmin.
> Is that qpsmtpd's job though? If there's a WARN, EMERGENCY event, then a
> professional infrastructure already has some application testing for that and
> firing emails. It's an industry after all. If it's a DIY shop like me, cron
> and perl do great.
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.
>> 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.
> I think that the bigger issue is getting admins with an urgent need for a
> unique method of email queue processing onto the qpsmtpd platform. Think of
> all the poor sharepoint admins out there that would *clearly* benefit.
I know these mail users well. I sell them tech support. Hundreds of these
people have built a Mail::Toaster to stick in front of their Exchange server.
Hundreds more followed the copy/paste instructions from my site to build
themselves a mail server and haven't ever touched it since. Scary, I know. But
nearly ever week I get a "I build your mail toaster X years ago and today it
broke, can you repair it?" order.
The vast majority of folks in that crowd aren't going to touch a "perl only"
approach that requires them to understand perl in order to use it effectively.
They need something they can get working on their own and they need to feel
like they know how to control it.
> How about a Web GUI front end? How about a stats gui? Are either intrinsic
> to QPSMTPD? No. But Microsft trains managment/lowest common denominator
> admins that apps should have a gui and management likes numbers. How about
> making a lightweight live CD to spin-up in a VM? Will it cluster? Lots of
> ways to go without changing what's working at the core of qpsmtpd.
I happen to believe that a reliable way to gather and process statistics about
the health of the mail server is a very important function. For perl hackers,
qpsmtpd is already good enough. We have an extensive arsenal of command line
tools and perl to slice, dice, report, and present the data however we need.
But that's not good enough for the "average" sysadmin. I think qpsmtpd should
have much more consistent logging. Consistent enough that we could (and I'd
argue should) include plugins for major monitoring systems like munin, cacti,
nagios, etc. That would provide an out-of-the-box way for our less skilled
users to show pretty graphs to the pointy haired men who write their paychecks.
It would help those sysadmins feel like they understand it.
> 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};
};
Now you can upgrade and your existing config works as you expect.
Matt
