While playing around with Exim quotas, I stumbled upon another problem,
again at least in Exim 4.04.
The retry rules allow specifying errors like this: 'quota_7d', which
should apply for quota errors, when the mailbox was not accessed for
more than 7 days.
So, I sent a big mail to a box and set the atime with 'touch' to April
1st, just to be sure:
<snip>
[root@largo /etc]# stat /var/mail/luser
File: "/var/mail/luser"
Size: 4253574 Filetype: Regular File
Mode: (0600/-rw-------) Uid: ( 1989/ luser) Gid: ( 12/
mail)
Device: 8,1 Inode: 13 Links: 1
Access: Mon Apr 1 00:00:00 2002(00039.16:00:49)
Modify: Mon Apr 1 00:00:00 2002(00039.16:00:49)
Change: Fri May 10 15:41:53 2002(00000.00:18:56)
</snip>
Then I tried to send the same big mail again, which would exceed the
users quota.
When running exim with -d+transports, it reports:
Exim quota exceeded for /var/mail/luser: time since file read = 5h4m1s
Clearly, April 1st is a lot longer past than just 5 hours.
When poking around in src/transports/appendfile.c, I saw what the
problem was:
The atime is stored in addr->more_errno, if the quota is exceeded.
more_errno, according to src/structs.h, is only a signed short int,
which on IA32-Linux[0] (and I believe on most other systems, too) is
only 16 bit long.
So, you should access your mailbox at least twice a day to receive sane
results, as it will overflow after every 32767 seconds...
HTH,
he
[0] uname -a
Linux largo.netway.at 2.2.14-nwy1G #2 SMP Thu May 17 12:20:24 CEST 2001 i686 unknown
