> 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? > > 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. > Which is more important, keeping existing users, or reaching > new ones? I'm adverse to significant changes as the concept that the old is the "devil you know." That's attractive all by itself to any admin that likes to sleep on a regular schedule. > > To reach new users, qpsmtpd needs to lower the barriers to > entry. Free anything does not have barriers to entry. The value proposition doesn't fit the model the phrase "barriers to entry" comes from. (non-free things) > Right now, > understanding it is a large barrier to entry. I disagree with this. I'm a PERL newbie and I "get it." No, I don't know the plumbing. I don't want to know. But the plugins file is self-explanatory. I cobbled together my own plugins too in the time it took for me to get a handle on postfix's syntax. If the goal is to expand the userbase, then I think more documentation might help. 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. 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. > If the > new version is better, users will upgrade, even if there's > effort involved. I'm not saying we should ignore the legacy > issues. Just that there are ways to handle legacy changes. What's "better?" Better for me is not changing the config. If I want to migrate, then nothing better than copying the config over and turning it on. A sane production environment with lots of hands involved has a strong bias for not changing configs. No one is more "right" or "wrong" including me. I'm much more of an admin than a PERL hacker. Qpsmtpd totally works for me now and better than postfix in many ways. Just my $0.02.
