Linux - ServerThis forum is for the discussion of Linux Software used in a server related context.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I am going to setup postfix mail server for my client on RHEL 5.5 64 bit server, But I don't know how do I set quota in users mail boxes as I have found postfix don't have this feature, so If I will use linux disk quota technology in my mail server for solving this purpose will this help.
Please suggest procedure if it is possible or any other alternate.
I don't want to do patching to postfix as this is server is in production. Thus I want to follow standard procedure which is available in RHEL. My question If I choose disk quota will it help.
Here is another option that may provide some help: http://johnny.chadda.se/article/mail...rey-and-dspam/ Search for the work 'quota' in the page. You will want to look through the comments too. It uses virtual users (don't know if you do or not) and the POP/IMAP application rather than Postfix to enforce quotas. It may work without virtual users.
You may be able to do this with disk quotas, but I suspect that the effect will be to "push the problem elsewhere", much like the pipe leaks in cartoons where they put their finger on one leak and it springs up somewhere else. In order to use disk quota, you will need to put the mail into a directory and assign limits to that directory, or user, or something, somehow. Not sure how you would do it, but it sounds like it would work. Note, 'virtual users' still stores the mail in a directory. It is just in a central location such as /var instead of the user's home directory.
The problem I think you will see with disk limits is that if someone goes over the quota, the mail programs won't see it that way. Instead they will see a disk error and defer the mail rather than bounce and that this could cause a clog in your Postfix queues or cause a bunch of bad traffic for rejected and deferred mail that will cause issues.
Thanks I also suspect might disk quota will create such problem, but anyway I will try this solution also mentioned in this link provided by yoy if any problem comes I will update you. Thanks once again for support.
The problem I think you will see with disk limits is that if someone goes over the quota, the mail programs won't see it that way. Instead they will see a disk error and defer the mail rather than bounce and that this could cause a clog in your Postfix queues or cause a bunch of bad traffic for rejected and deferred mail that will cause issues.
This is not true in my experience. For me, Postfix generates and sends a bounce message. The wording of the message is a tad cryptic for inexperienced users, but the gist of it is is that the recipient has exceeded their disk quota.
This is not to say that disk quotas are without problems. Two issues I've encountered are:
1. The pop/imap server (Dovecot in my case) is unable to write to its uidlist files when quota is exceeded if those files are stored along with mail. There's a workaround for this (see link below).
2. It's impossible to move mail to Trash using imap (either a client or a imap-based webmail app) as most imap servers first copy the mail to Trash and then delete it from the original location. The 'copy to Trash' part fails when the disk quota is exceeded.
So both problems are on the imap/pop side rather than issues for Postfix. You may want to research how you imap/pop server hands disk quotas. Some info about Dovecot is here: http://wiki.dovecot.org/Quota/FS
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.