On Mon, 10 Nov 1997, Jason Costomiris wrote:
> 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?
because it's trivial to do? because you don't have to do it unless you
need it? because it's less work than completely changing the way mail is
handled on your system?
but the bottom line is that it's YOUR system. run it however you like.
My system is MINE, however, and i'll run them how *I* like.
> : > 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:
what this means is that (since procmail is such an important part of my
systems' mail handling capabilities) qmail is not useful for me.
> | preline procmail
>
> isn't all that difficult.
no it's not difficult. the PITA factor comes in because it has to be
done for every account. As i said, i use procmail as the local delivery
agent - which means that i need a global setting for it, not a per- user
setting.
> : 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 ?
yes, as i said in my last message, it is part of my system's spam blocking
setup. every user on my system enjoys the benefits of that.
> : 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.
it's MY system. I really don't care if users wish to have their own
~/.procmailrc or not - that is entirely up to them. I, however, make
great use of it to block spam.
switching to qmail would involve a hell of a lot more time than 30
seconds. It would take days to duplicate the functionality of my
current setup, and at the end of that time i would have a setup no
better than what i already have. after that, i would have to enjoy the
dubious pleasures of reproducing the setup on all of the mail systems
that i am responsible for.
> : 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.
shit happens. i deal with it. no spam-blocking system can be 100%
effective - there are new spammers and new spamming domains all the
time. they have to spam at least once before they can get in any
blocking list.
My /etc/procmailrc rules catch nearly all of the spam which makes it
through the spamm address, domain and IP blocking rules.
> If you want a more serious spam solution, contact Paul Vixie. He'll
> offer you BGP peering sessions that blackhole routes for spammers.
i could make use of that if they also distributed plain text lists of
spamming network/netmasks, however a lot of spam is relayed through
other systems which are NOT blocked.
blocking spam requires a multi-tier approach.
> : - 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?
i suppose so. it seems like they are comparable features.
> : - 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.
no, the battle is lost if the spam gets into my (or a user's) inbox.
even then it's only a temporary loss because any spam which does make it
that far gets added to my blocking lists.
as mentioned above, shit happens sometimes. i deal with it.
> : 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.
how else do you create the lists of spammers and spamming domains? the data
has to come from somewhere, it doesn't just magically create itself.
> : 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.
not hard, just a PITA. it can take pine a minute or two to read in some of
my mailboxes (pine doesn't cope with multi-megabyte spool files very well).
> 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).
i don't like mutt. whether it's better or not is a matter of opinion. i
don't want to run it.
> : what's so difficult about adding the following lines to
> : /etc/mail/sendmail.mc?
> :
> : # to block incoming junk
> : HACK(use_spammers)dnl
> :
> : [...deleted...]
>
> They're not ready for prime time yet. Notice it's not FEATURE(), and it
> is HACK()?
they work. i don't care whether it's called a "FEATURE" or a "HACK" as
long as it works and does what i want it to.
> : 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.
i have yet to see convincing arguments that maildir or ~/Mailbox is any more
secure than /var/spool/mail
> 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.
or you could just keep up to date with the latest version of sendmail.
there are no (known) security holes with sendmail 8.8.8. if any are
discovered it will be a matter of few days (at most) before 8.8.9 is
available as a debian package.
> 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. :)
Q: "qmail doesn't work with the way my system has been set up for years".
A: "change your system then. DJB knows better than you how your system
should be set up".
yeah, right.
craig
--
craig sanders
networking consultant Available for casual or contract
temporary autonomous zone system administration tasks.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
