[Exim] Deny sending if over quota possiblity

Page principale
Supprimer ce message
Répondre à ce message
Auteur: S. Yoder
Date:  
À: exim-users
Sujet: [Exim] Deny sending if over quota possiblity
Almost a year ago I asked if there was a way to deny users sending
ability if they were over quota that was built into Exim. Of course
there wasn't, but there was the ability to run something external. After
testing Exim to my satisfaction, implementing it, and saying a not so
fond farewell to our Exchange server, I've finally had time to revisit
the possibility for this little feature. I would be much obliged if a
few could take a look at this and tell me if I'm headed for a security
risk. I am not using this on the production box yet.

Setup:
Exim 4.20
Max potential users: 25
Current users: 12
Using Exim's quota facility and not OS's.
Courier-IMAP and Maildir if it matters.
Server behind firewall, plus has its own firewall rules.
Simple scripting and intermediate Perl are the limits of my programming
ability.

ACL @ acl_smtp_rcpt:
# Deny sending for local users if almost at quota
       # only run for local domains
deny  sender_domains = +local_domains
       # list all addresses that are aliases
       # that we don't want to check for quotas
       senders = ! ^postmaster@.*:\
                 ! ^root@.*:\
                 ! ^webmaster@.*
       # verify email client expunges on emptying the trash
       message = You have too much email stored. Please delete some\n\
                 and empty the trash. Then you can send.
       log_message = $sender_address_local_part is over send quota
       condition = ${run{/usr/bin/sudo -u root \
                   /etc/exim/check-sendquota.sh \
                   $sender_address_local_part}{no}{yes}}


"check-sendquota.sh" is a bash script I wrote. What it does is a 'du -s'
on the sender's Maildir (there is a check to make sure the directory
exists and that it is a directory), then looks at the quota file for
Exim. From the quota listed for the user a percentage, specified in the
script, is calculated. If the storage space used is more than the
percentage of the quota then it exits with a status of 1, otherwise a
status of 0 is returned. I can post it if anyone needs to see it.

What bothers me with this setup, and keen eyes have probably already
caught it, is that the script must be run as a user that has access to
do the 'du -s' on the given directory. From what I have learned and
understand is that Exim runs the ACLs as the user it was compiled to run
as, which means that it cannot run the 'du -s' properly. Instead it
needs to run as the user who owns the directory or as a super user. The
only way I could figure out how to do this was by using sudo. Now I did
setup the sudoers file so that only this command can only be run with
sudo as the user Exim is running as and only on the localhost.

It really bothers me that I have to run this script as root, but it has
been the only way I could come up with. Is there anything I could do to
make it safer? I considered having some helper application that would
periodically get each user's Maildir usage and write it to something
Exim could read as is. However, from what I could figure, is something
like that would have to run very frequently because in a business
environment you don't want something to be delayed an hour because a
file hasn't been updated. And even then the app would have to run as a
user that could get the information needed.

The whole reason for doing this is because I have found that denying
sending gets the users to clean up their mailbox very quickly, where as
the warning email from Exim's quota facility can be ignored. In fact the
situation occurred just this past week where one of my users went over
their quota, had ignored the warning email, and incoming email to them
was being deferred. The only reason they finally cleaned out their
mailbox was because I happened to be checking in from home, during the
first holiday I'd had in a year [grin], and called them about it.

Pointers, nudges, other ideas, and criticism greatly appreciated.

Thanks,
Stef