You could always disable caching globally, possibly enabling it for any users who don't have MMDF spools.You could disable caching for those users, which would turn off the log messages (since Qpopper wouldn't attempt to create a cache file).That's potentially thousands of users ... but I need to verify how many users are actually seeing it. But, probably, it will make more sense to do for everyone or no one, not for a subset of our user base.
Well, the code is working as intended. MMDF spools are excluded from caching, so there's no need for a script to check if some users aren't getting the error.I'll have to write a script to look and see if there's any sessions that don't get it ... I'll have to figure out the right way to write that script ... there's no way I can do it by hand.The daemon's that are doing this are our KPOP daemon and our SPOP daemon, both of which are standalone instead of inetd based, and are invoked as:/usr/local/lib/kpopper 1109 -k -K pop -s -S -T120 /usr/local/lib/spopper 995 -s -S -T120 -f /etc/mail/pop/spopper.configDo these daemons generate the error for all users, or only some?
This seems a lot to me like a bug in MMDF support.Are the spools in MMDF format or not? That's the main question.Yes, they are. Sorry I didn't say that in the original message.
It would be nice to support caching with MMDF spools, but my impression is that very few sites use them, and it adds a lot of complexity and potential bugs. However, contributions of code to support them are always welcome.
