Re: compile error
"Chris L. Mason" [EMAIL PROTECTED] writes: Technically it's a bug. main() should always return int... Dan always calls _exit(stat), so main() _does_ return an integer, regardless of the declaration. I always just assumed Dan was trying to make a statement of some kind as he certainly wouldn't have done this by mistake. :) In 1996, Dan said, ``In case anyone's curious: I use void main() because it shuts gcc up. If there is ever a compiler dumb enough to break void main(), I will happily advise everyone to use a different compiler.'' From this we can infer that some version(s) of gcc, on some platform(s), made a lot of noise over "int main()"; perhaps when it contains no return statements. "void main()" works identically, with fewer complaints. Len.
Re: Anal-ness
Russell Nelson [EMAIL PROTECTED] writes: An OSI-approved Open Source license...And RMS (Richard M. Stallman) Note that many things are good and right, though unblessed by OSI and Richard "Source code for the workers or we shoot you" Stalin. Qmail's restrictions may be a "moral" downer for some. However, in a practical sense the restrictions don't prevent any desired use of qmail--except including a forked qmail in distributions. Note, too, that Dan seems to define "forking" differently than Eric Raymond. Changing the locations of vital files (usually for no particular reason) counts with Dan as a "fork". This may not matter for atomic programs, but for complete systems, like qmail, it does. As Dan pointed out before (and I hadn't realized till then), the author is responsible for supporting his product on every OS that runs it--RedHat and Debian, but also FreeBSD, Solaris, AIX, HP/UX and Unixware. Dan doesn't want to be ``faced with a support nightmare---forever'', and I can't say I blame him. Len.
Re: big rcpthosts file
Peter Gradwell spake unto me and said: - searching a fairly empty (5 lines) rcpthosts file and then searching morercpthosts, or Um, that should be '(50 lines)', meaning 'your 50 most commonly used domains' (man qmail-smtpd). When a domain is found in rcpthosts, then morercpthosts is not touched. Depending how common 'most common' is, morercpthosts will not be used much. - just searching a large rcpthosts file. Um, qmail-smtpd doesn't actually search the rcpthosts file. It parses the file into an in-memory cdb, and searches that. qmail-newmrh parses morercpthosts into an on-disk cdb, which qmail-smtpd searches from the disk _when necessary_. So your choice really is: - searching a fairly small (50 domains) in-memory cdb, and then searching a large on-disk cdb when necessary, or - just(!) searching a large in-memory cdb. (Remember, large in-memory structures are paged, so disk I/O is required in either case, with a suitable definition of 'large'.) Looking at the source code suggests that search speed is not the issue; memory is. Smaller qmail-smtpd processes mean more qmail-smtpd (and qmail-remote) processes, which means greater concurrency. No doubt Dan has profiled this, and seen that the bottom line is greater overall throughput. Len.
Re: big rcpthosts file
Frank Greven spake unto me and said: Should I only use rcptshosts or not? You should use morercpthosts, because Dan knows what he's doing. If it's a question of memory - because of what you called in-memory cdb - what is the needed size of RAM? I can't answer that; this is a case of 'profile, don't speculate.' If you're using just rcpthosts, and your performance is acceptable, then obviously you _can_ just keep doing what you're doing. Or maybe the whole diskussion is wasted time because either a small Linux Pentium system with 128 MB RAM and let's say 10,000 mails per day will never run into a performance leak? Could be (see above). However, total throughput isn't the only test of load. You should install qmailanalog, if you haven't already. Look at your average concurrency. If it is high, then you should _definitely_ use morercpthosts--and also use concurrencyremote to allow more concurrent deliveries. If your concurrency is very low, you probably don't have to change anything. HTH, Len.
Re: Server cluster
Michael Boman spake unto me and said: Let me see if I get this right, it is OK to share the /home/vpopmail directory, but not the others? Anyone have ideas how to keep the qmail controlfiles etc up-to-date on each computer, or can I just share that directory (/var/qmail/control and maybe /var/qmail/alias). /var/qmail/queue /var/qmail/queue is the one thing you simply CANNOT share; qmail cannot queue messages through NFS. (Read INSTALL.maildir; you'll see that Dan takes a dim view of NFS.) /var/qmail/control Sharing /var/qmail/control is possible, if you're careful. It probably means that home directories are NFS mounted, and passwords are NIS shared. This in turn means: 1. mbox delivery is deprecated; use Maildir. See INSTALL.maildir, INSTALL.mbox and INSTALL.vsm. 2. Mail will bounce unless you follow the steps in FAQ 4.9: "How do I make qmail defer messages during NFS or NIS outages?" An alternative to sharing is to use sed and rsync (with "-e ssh"). The qmail Makefile contains an elegant use of sed for that purpose. /var/qmail/bin You certainly can share /var/qmail/bin if you want. Make sure the qmail users and groups have the same IDs on every host. Also, paths need to agree: for example /var/qmail/queue should always get you to the right place. /var/qmail/alias Can be shared. Remember, it's a home directory; use Maildir. Also, it's your problem to make sure that .qmail-* files work everywhere. HTH, Len.
Re: 3 quickies!
"Marc-Adrian Napoli" spake unto me and said: What i'm after is a solution that falls into place at the qmail-send/qmail-local stage that will quickly check the headers of the message to be delivered locally first for any particular strings. (Silly email addresses or anything with the word "buy now" or "sell now" etc) I recommend that you be _VERY_ careful with this idea, especially if you are an ISP. In particular, bouncing emails may anger your customers, and destroying emails can get your butt sued off. Suppose one of your customers is sent an email from his stock broker, saying "Sell Now" Your customer never gets the email, and loses his shirt, because of your spam "protection". You will deserve whatever happens to you. Other than RBL-blocking, and making sure _your_ relay is closed, I recommend that you only use filters which are _explicitly_ approved by _each_ affected customer. Deciding for your _customer_ which emails look "bad" to _you_ is very foolish. Check out http://www.pobox.com for a good example of spam filtering which is _customer_ approved. Len.
Re: 3 quickies!
Paul Schinder spake unto me and said: At 10:24 AM -0500 12/23/99, [EMAIL PROTECTED] wrote: Check out http://www.pobox.com for a good example of spam filtering which is _customer_ approved. ...the example is poor, IMHO. I have a pobox account for non-work related mail, and I had their spam filtering on for a while before finally turning it off. It tagged things as spam that weren't. It missed tagging most real spam. In short, it wasn't any help at all. Oh, I agree completely! I let pobox mark my "spam" emails, and it's hideously inaccurate. All I meant was that their bad spam "protection" is truly optional, which is good. ...what I'd pay extra for, and what they don't offer (at least the last time I checked), is RBL+DUL+RSS on my incoming mail stream... Agreed; that might be handy. What I've been doing for a while is sending BCCs to a separate folder. Once a month or so I glance through the folder. It usually contains about two dozen emails, almost all spam. No fuss, no muss, and I've only seen about half a dozen pieces of spam get through it in about 2 years. I guess spam doesn't send me into a killing rage, when I get to meet it on my own terms. (But if you're lynching spammers, do invite me along.) Len.
Mail abuse
"David L. Nicol" spake unto me and said: what keeps spammers from faking envelope-from and using include-in-bounce features to relay spam content? Nothing; see http://cr.yp.to/docs/mailabuse.html for this and other more heinous possibilities. Is it possible that a subject of "failure notice" will some day not be sufficient to prevent this possibility? It's not clear what you mean. If you destroy bounces, you prevent that attack; however you also prevent people from seeing legitimate bounces. In general, it is impossible to make bounces unforgeable. Len.
