Procmailrc email processing has issues with disk quota

[verne]

I have either found a bug, or have a config issue – or just don’t understand things !!

First, does VirtualMin GPL support user disk quota processing/checking when handling an incoming mail message via procmailrc ?

My workaround is to edit both lookup-domain.pl and lookup-domain-daemon.pl to force qmode to be HOME all the time — as presently the logic to set qmode ends up with it being blank/null. We only recently switched to postfix from sendmail as well as to/from using Maildir VS /var/spool/mail (also called /var/mail) so any of those settings could be in play.

The code for setting qmode in lookup-domain.pl is

$qmode = &mail_under_home() && &has_home_quotas() ? “home” :
&has_mail_quotas() ? “mail” : undef;

and one or more of those routines (mail_under_home, has_home_quotas and has_mail_quotas) will obviously give different answers depending on sendmail/postfix as well as the Maildir selection/setting.

My general take on this is – when /var/mail and the Maildir area under /homes/ are on the same filesystem, the user’s disk quota covers both, so I am not sure why qmode, at least in my environment, would ever be blank. And as the routines mail_under_home has_home_quotas has_mail_quotas are most likely used in other places too, I hesitate on editing them so they give different results.

And instead of sending message after message, a test I came up with which I hope is valid is:

cat big-file.dat | /etc/webmin/virtual-server/lookup-domain.pl verne@mingocountywv.com
Disk quota for verne@mingocountywv.com of 283115520 blocks has been reached.
141175749723247

where the verne account is already over quota (and 141175749723247 is the internal VirtualMin Domain ID). The above test was done AFTER I made my custom edit to force qmode=HOME all the time, as the original code appears to not properly check for being over quota.

That is, if I understand /etc/procmailrc, I expect to get a 73 return code, which in turn results in /var/log/procmailrc.log logging:

procmail: Program failure (73) of “/etc/webmin/virtual-server/lookup-domain.pl”

My custom edit seems to be the only way to get a 73 exit code when over quota.

OR – I need to step back and think this through as perhaps its a non-issue as the test msg never gets delivered when the user is over quota.

And I hope I am not treading into Pro features here

thoughts anyone?

Verne

[calport]

@verne

First, does VirtualMin GPL support user disk quota processing/checking when handling an incoming mail message via procmailrc ?

I don’t program in Perl so much of what you said I was unable to understand.

I write to point out that quota readings in Virtualmin go haywire if the maildir is located outside /home. If you have moved directories around then it might cause the issue you describe.

That’s all I wanted to say.

[verne]

while my environment is complicated by using SELinux, at the moment I have it in permissive mode so everything it does not like should still be allowed but reported upon as well – just wanted to throw that out there in the interest of full disclosure.

More testing shows yet another issue – there is code in lookup-domain that calls list_domain_users, then pulls out an array (or hash?) of just the single user being processed. When I dump that array, I get UnDef values for several quota items when lookup-domain is executed inside of procmail (by sending an email message), but do get proper values when tested using my CAT [file] method above.

I do not know if this is a bug, or I am not testing it properly, but with the UnDef values the code does not recognize the exceeded quota occurance

I should note this occurs only when the lookup-domain daemon on port 11000 is NOT running – meaning the local perl code in lookup-domain executing inside procmail has to do all the work. When I do start up the daemon, it does return the correct quota values for the user being processed. Perhaps I simply need to always run the daemon (with my custom edit mentioned above for QMODE) all the time and not worry about the other block of code.

I can cross post all of this into github as an issue, but first wanted to see if I had made any basic assumption errors !!