mails ending up in /var/spool/mail/webXX_user ...

[jmroth]

... when the user/group is over quota during delivery or so

Is it supposed to be that way?

[falko]

Do you use mbox or Maildir? What's in the mail log?

[till]

If you use maildir, you can try to disable the quota procmail recipe. Then the quota is handled completely by the linux system quota. This might solve the problem.

Open the file

/root/ispconfig/isp/conf/procmailrc.master

and comment out the line:

INCLUDERC={PMDIR}/.quota.rc

Then go in the ispconfig interface and change something in an account of y user where you got this problem and save the user. The procmailrc will then be rewritten.

[jmroth]

Yes, I am using Maildir. Users seem to be quite resilient sometimes, as there is much going on in my spool directory

@falko:

Dec 12 09:07:57 new postfix/local[25508]: DD2D37FBA7: to=<webNN_user@server>, orig_to=<user@domain.com>, relay=local, delay=21, status=sent (delivered to command: /usr/bin/procmail -f-)

@till:
ok I will try that

[jmroth]

Hmmm... while looking at .quota.rc I still don't really see how the line

let HD_QUOTA=\`quota ${LOGNAME} | sed -n 3p | awk '{print $3\'}

works.
As I said in some other thread, you at least have to use quota -v.
And even that won't work if user quotas are -1, so probably quota -vg is needed in that case, of course you would need to erase the trailing _user from webxx.

In fact, delivering to /var/spool/mail was what happened when procmail didn't detect something was wrong and handled the mail over to the system.
So handling it over to the system directly will probably make no difference, but a working email quotacheck would.
And again as I said before, it would be way cooler to separate mail from web quota, but I do understand that it is currently not possible.

Regards
~jm

[jmroth]

Well well I have played a little bit with this.
I guess the problem here was that my /var directory has no quotas enabled, so the MTA's attempt to do some kind of delivery succeeds here but as far as the users are concerned the mail has just disappeared.
I have now recoded the quota.rc file a little bit:

...

:0  # if QUOTA is set to something, then..
* QUOTA ?? .
{
        FS_GROUP=`echo ${LOGNAME} | awk -F_ '{print $1}'`
        QUOTA=`let FS_GROUP_QUOTA=\`quota -vg ${FS_GROUP} | sed -n 3p | awk '{print $3}'\`*1024
               let FS_USER_QUOTA=\`quota -v ${LOGNAME} | sed -n 3p | awk '{print $3}'\`*1024
               let FS_GROUP_QUOTA_USED=\`quota -vg ${FS_GROUP} | sed -n 3p | awk '{print $2}'\`*1024
               let FS_GROUP_QUOTA_FREE=${FS_GROUP_QUOTA}-${FS_GROUP_QUOTA_USED}
               let FS_USER_QUOTA_USED=\`quota -v ${LOGNAME} | sed -n 3p | awk '{print $2}'\`*1024
               let FS_USER_QUOTA_FREE=${FS_USER_QUOTA}-${FS_USER_QUOTA_USED}
               if [ $FS_USER_QUOTA == 0 ]; then
                if [ $FS_GROUP_QUOTA != 0 ]; then
                 # we have unlimtied user filesystem quota but the group is limited
                 if [ "$FS_GROUP_QUOTA_FREE" -lt "$QUOTA" ]; then
                   QUOTA=${FS_GROUP_QUOTA_FREE}
                 else
                   QUOTA=${QUOTA}
                 fi
                else
                 QUOTA=${QUOTA}
                fi
               else
                # check if the user has much space left but the group it belongs to has not
                if [ "$FS_USER_QUOTA_FREE" -lt "$FS_GROUP_QUOTA_FREE" ]; then
                 QUOTA=${FS_USER_QUOTA_FREE}
                else
                 QUOTA=${FS_GROUP_QUOTA_FREE}
                fi
               fi
               echo ${QUOTA}`

        :0
        * > ${QUOTA}
        {
...

Now it does what I want it to do.
Note that I have just removed the MAILBOX_SIZE_REPORT_ part as it seems to be unused.
This may not work if people have modified their account scheme (webnn_xxx)..

Also it might be useful to use LOGFILE="/tmp/procmail.quota.$LOGNAME.log" at the very top of the file

Sorry this is not really diff-style but I guess you get the idea.

Regards,
~jm

[jmroth]

Hmm.. by enabling verbose procmail logging I have seen more stuff that makes me worry...

procmail: Executing "/home/admispconfig/ispconfig/tools/clamav/bin/trashscan"
procmail: Assigning "LASTFOLDER=/home/admispconfig/ispconfig/tools/clamav/bin/trashscan"
procmail: Notified comsat: "webnn_xxx@:/home/admispconfig/ispconfig/tools/clamav/bin/trashscan"
From ba@bla.com  Tue Dec 13 10:07:11 2005
 Subject: XXXXX
  Folder: /home/admispconfig/ispconfig/tools/clamav/bin/trashscan         15438
LibClamAV Error: Wrote 0 instead of 512 (/local/home/www/webnn/user/webnn_XXX/tmp/clamav-c358d0e95a4cd461/main.db).
cli_untgz: Disk quota exceeded
LibClamAV Error: cli_cvdload(): Can't unpack CVD file.
LibClamAV Error: Can't load /home/admispconfig/ispconfig/tools/clamav/share/clamav/main.cvd: CVD extraction failure
ERROR: CVD extraction failure

Maybe it would be wiser to unpack it in /tmp or so after all?

Oh and since we're talking about /tmp, I have lots of mailchk.* files in there. They seem to come from html-trap.rc and as it seems are not always cleaned up although there's an unlink in there...

[jmroth]

I have done more digging here as I would like to try and be flexible with customers...
Even by uncommenting the quota recipe, procmail is still involved, and if it fails to deliver to my partition containing the homes (which has quota enabled) it falls back to /var/mail (which has no quotas enabled).
Since people do not have shell access etc. they will never get to the mailbox in /var/mail.
One solution would be to set the ORGMAIL variable in .procmailrc too.

ORGMAIL=$MAILDIR

Since procmail defaults to ORGMAIL when it arrives at the end of the procmail file, it will try again to write to the filesystem that is over quota and will then bounce the mail.
I will probably use a cronjob to send mails to those people that are over (soft) quota to inform them that after the grace period time, mails will no longer be delivered. However in the case where the web size has been restricted globally it will be difficult for a simple script to find out who is the admin user for the web (the filesystem group) that is over quota...
Just thinking..
Regards,
~jm

[falko]

Originally Posted by jmroth

One solution would be to set the ORGMAIL variable in .procmailrc too.

ORGMAIL=$MAILDIR

Since procmail defaults to ORGMAIL when it arrives at the end of the procmail file, it will try again to write to the filesystem that is over quota and will then bounce the mail.

Thanks for the hint! We'll test this.