On Mon, Nov 10, 1997 at 08:40:35PM +1100, Craig Sanders wrote: : > Yeah, and? It allows you to streamline your quota setup. It also allows : > you to have a smaller /var. : : what does "the qmail way" allow you to do with quotas which you can't : do with the standard /var/spool/mail? i can think of one thing which : the standard way allows which the "qmail way" doesn't: having separate : quotas for /home and /var/spool/mail
Why should I have to manage quotas for three filesystems instead of two? I already quota /home and /tmp, why on earth would I want to have to manage it for /var too? : > Why do you need to do this? If your users need to sort their mail, : > it's quite easy to use procmail in conjunction with a stock qmail : > setup. You just need to read the FAQ. : : The FAQ told me how to use it from a ~/.qmail file. i didn't want to : know how to do that (it's damned obvious), I wanted procmail as the MDA. I agree with you, for machines with sendmail as the MTA. Procmail has less overhead than deliver or mail.local. However, it adds overhead on qmail systems, and isn't really used except for guys like us who read a bunch of mailing lists using shell accounts, instead of pop3 mailers that have their own filters. For the 5 - 10% of users that actually use procmail, I think making that ~/.qmail file that says: | preline procmail isn't all that difficult. : there are several reasons why i need to do this: : : 1. i don't have to have a "|procmail ..." .forward or .qmail file in : every user's home dir. Does every user on your box use its features, or does it just deposit mail in /var/spool/mail/$USER ? : i see procmail as an INTEGRAL part of my systems' mail capabilities, : not as a tacked on piece of cruft. Again, for YOU. Not for all of your users. As a system admin, you should be willing to have to take 30 seconds to setup your own environment, and have a nice, stable, secure, fast environment for the rest of your userbase. : 2. procmail is part of my 4 tier spam filtering system. Why??? It's too late then. By that time, you've already accepted the mail. If you want a more serious spam solution, contact Paul Vixie. He'll offer you BGP peering sessions that blackhole routes for spammers. : - sendmail check_* blocks incoming spam from known spam domains : and spam users, and also prevents spammers from hijacking my : systems You mean the way control/badmailfrom and tcpcontrol do? : - procmail as local delivery agent catches a large percentage of the : spam which makes it through tiers 1 & 2 with a handful of simple : rules in the system-wide /etc/procmailrc file Too late again. You've already lost the battle by accepting the mail. Now you're on the run trying to get rid of it so you don't have to read it instead of concentrating on not accepting it to start with. : all spam caught at this stage is saved in : /root/mail/probable-junkmail, and i read through it every so : often. so far, it hasn't caught anything which it shouldn't : catch...if it ever does, i'll just bounce it to the intended : recipient. Yep, nothing like making extra work for yourself. Love it. : great. so i have to quit pine every so often and restart it so that the : wrapper script can move my mail to where it should have been in the : first place. q, y, pinq. Wow. That's hard. Actually, I believe that pine 3.96 and higher support maildir. At least it does on a box I have an account on that runs OpenBSD and qmail. Mutt supports maildir too. Mutt is *much* better than pine, IMHO (this from someone who used pine for about 4.5 years). : > Uh, I've done a good deal of work constructing a set of check_* rules : > that I use to restrict relaying and drop spam. qmail was a snap by : > comparison. : : what's so difficult about adding the following lines to : /etc/mail/sendmail.mc? : : # to block incoming junk : HACK(use_spammers)dnl : HACK(use_spamdoms)dnl : HACK(check_mail)dnl : : # to prevent relaying : HACK(use_ip)dnl : HACK(use_relayto)dnl : HACK(check_rcpt4)dnl They're not ready for prime time yet. Notice it's not FEATURE(), and it is HACK()? : qmail might have some good features, and it might conform to the RFCs : a bit more closely than sendmail does, but i still don't see any : compelling reason to use qmail rather than sendmail. Maybe if i needed : to run huge mailing lists i might consider a dedicated server running : qmail. The main reason is the default behavior for qmail is much more secure than sendmail. To make sendmail more secure, I need to change the DefaultUser entry, I need to rip out Mprog, and I need to add all kinds of custom rulesets. : > As opposed to the machine becoming overwhelmed from delivering to : > a /var partition that's mounted accross several machines, as you : > suggested with home dirs? : : the point was that his NFS argument against /var/spool/mail was : irrelevant because home directories are often NFS mounted too (and : would therefore suffer from the same potential problems) - and in that : situation, the load would be much worse because the automounter would be : mounting and unmounting user home directories whenever mail arrived. Actually, the point of Dan Bernstein's arguement against NFS file locking has to do with the fact that mbox's need to be locked. maildirs do NOT. Also, as for the automounter business, just mount the fs once. Don't automount it. There, problem solved. I won't even charge for that one. :) -- Jason Costomiris <>< | "VMS is about as secure as a poodle [EMAIL PROTECTED] | encased in a block of lucite.... http://www.jasons.org/~jcostom/ | .... about as useful, too." #include <disclaimer.h> | --some guy I read on Usenet -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
